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FOREWORD 


INTRODUCTION 

MILCOM  1  (January  1982)  and  Ml  LOOM  II  (January  1983)  were  the 
first  two  seminars  of  a  series  sponsored  by  American  Defense 
Preparedness  Association  to  provide  a  forum  on  policy  level  issues 
concerning  military  computers  and  software.  The  issues  of  policy 
problems  in  doctrine  and/or  Implementation,  military  threat  to  the 
United  States,  computer  and  software  contribution  to  United  States 
capability  and  readiness,  economic  threat  from  technological  advances 
in  computers  and  software  by  United  States  allies  and  measure  to 
retain  the  United  States  position  have  all  been  presented  and 
discussed.  Perspectives  of  Congress,  both  Senate  and  House  of 
Representatives,  views  of  The  Department  of  Defense,  a  broad  spectrum 
of  industry  position  on  these  issues  and  relations  of  this  sector  of 
the  computer  and  software  community  to  academia  have  been  presented  in 
depth  but  not  yet  exhausted. 

The  topic  areas  of  industry  drivers  in  the  commercial  and 
military  marketplaces,  program  management,  computer  resources 
acquisition  and  management  by  DOD,  distinctions  between  the  commercial 
and  military  communities  such  as  short  and  long  life  cycles, 
standardization  practices  and  maintenance  support,  the  pros  and  cons 
of  software  and  hardware  standardization,  the  role  of  competition  and 
the  technical  areas  of  loglsitics,  automatic  testing,  evolutionary 
development,  technology  insertion  and  its  relation  to  program 
implementation,  have  all  been  treated  in  varying  depth  in  MILCOM  I  and 
II. 


MILCOM  111  represented  a  continuation  of  the  forum  on  military 
computers  and  software  with  emphasis  on  the  theme:  "Military  Computers 
and  Software:  Systems  Problems  of  the  Future."  In  tne  introduction 
to  this  theme,  the  Conference  Chairman,  Mr.  Alfred  W.  Hobelmann  of 
Perkin  Elmer  Corporation  stressed  particularly  the  goals  of  improved 
partnership  between  Congress,  DOD,  Industry  and  Academia  and  of 
improved  dialogue,  both  as  a  necessary  ingredient  to  an  improved 
partnership  and  as  a  source  of  problem  identification  and  solution  in 
meeting  national  technological,  military  and  economic  threats.  He 
cited  the  recent  remarks  of  Mr.  Frank  Press,  President  of  the  National 
Academy  of  Sciences  (The  Ooughnut  Effect)  in  this  regard  which 
stressed  dealing  with  the  problem  of  coordinating  many  activities  and 
agencies  and  evaluating  their  impacts  on  national  innovation. 

Mr.  Anthony  Battista,  Professional  Staff  Member,  House  Armed 
Services  Committee,  provided  a  comprehensive  and  penetrating  overview 
and  forecast  of  the  Congressional  appreciation  of  the  computer  and 
software  situation  and  probable  actions  concerning  it  in  the  near 
term. 


An  industry  perspective  on  the  computer  and  software  situation 
and  its  important  driving  forces  was  ably  presented  at  dinner  the 
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first  evening  by  Mr.  Robert  Miller,  Senior  Vice  President,  Data 
General  Corporation. 

This  report  condenses  the  attempt  of  the  symposium  to  reflect 
issues,  to  identify  interrelationships,  suggest  ways  by  which  the 
computer  and  software  community  partnership  can  be  strengthened  and  to 
point  to  ways  solutions  to  problems  in  this  area  can  be  defined  and 
articulated.  The  tape  recording  and  some  transcript  material  will  be 
retained  by  the  American  Defense  Preparedness  Association. 

SUMMARY 

MILCUM  111  keynote  "Directions  in  mission-critical  computers  and 
software",  delivered  by  Dr.  Edith  Martin,  was  a  comprehensive  and 
current  expression  of  problems  and  plans  in  the  area  of  military 
computers  and  software  and  their  technologies,  it  is,  therefore, 
provided  in  virtually  complete  form.  Problems  facing  the  Services  in 
the  future  included  computer  and  software  aspects  of  the  Air  force 
Space  Command,  the  Navy  effort  in  increasing  competition,  the  Navy 
Battle  Group,  and  Army  field  Command,  Control  and  Communications.  The 
problems  are  formidable  and  of  scope  to  tax  tne  evolving  technology. 
The  emerging  technologies  in  the  areas  of  software,  micro  elements, 
and  supercomputers  provided  an  excellent  overview  and  projection  of 
the  state  of  the  art  in  these  areas.  The  Evolving  Partnership  was 
provided  by  speakers  who  gave  incisive  discussion  of  the  partnership 
problem  and  a  complete  discussion  of  the  cooperative  effort  of  the 
micro-electronics  industry  to  meet  the  technological  and  economic 
challenges  from  abroad.  The  tone  of  the  discussion  was  set  by  Dr. 

Lyon  who  made  the  points  of  underuse  of  technology  in  the  U.S.  ana 
whether  or  not  we  are  bringing  our  tremendous  technology  heritage  and 
current  thrust  to  our  national  security  interest.  The  differences 
between  the  U.S.  and  the  U.S.S.R.  in  micro-electronic  technology  for 
defense,  our  commercial  computer  and  microelectronic  industry  which 
they  do  not  have  and  the  need  to  provide  leadership  as  well  as 
management  were  emphasized. 

Throughout  MlLCOM  III  there  was  a  much  improved  climate,  in 
comparison  to  MlLCOM  I  and  to  a  less  extent  MlLCOM  11,  in  the  matter 
of  reduced  contentious  debate  ana  more  earnest  effort  to  define 
problems  and  address  their  solutions.  The  appreciation  of  the  need 
for  a  Congress-DOO- Industry-Academia  partnership,  and  how  to  make 
further  progress  toward  it,  threaded  through  MlLCOM  111. 

There  were  a  number  of  statements  endorsing  the  continuation  of 
the  MlLCOM  series  of  seminars.  Suggestions  and  recommendations  from 
the  floor  and  panel  of  topics  to  be  included  in  MlLCOM  IV  included 

—  If  technology  is  being  driven  by  forces  out  of  DOD  and  industry 
control  we  need  to  learn  how  to  use  it,  emphasize  system- 1  eve  I 
management,  new  technology  and  technology  insertion  as  possible 
solutions. 

- Emphasize  the  management  and  insertion  of  technology,  budget 

cycles  and  the  management  and  configuration  control  of  software 
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(at  the  policy  level). 

— A  complete  analysis  and  discussion  of  the  "billion  lines  of 
code"  problem. 

- Solicitation  from  the  community  for  additional  topics  for  M1LCOM 

IV. 


A  statement  from  the  floor  indicated  that  there  is  a 
Congressional  rule  against  joint  DOU-Industry  working  groups.  In 
attempting  to  provide  an  industry  counterpart  to  the  OSO/DOO  Computer 
Systems  Interface  Working  Group,  announced  in  the  keynote  address,  it 
was  recommended  that  since  the  ADPA-MILCOM  committee  is  not  a 
professional  society  it  be  considered  as  the  industry  part  of  CSWIG 
and  that  congressional  approval  be  obtained  for  it. 

The  assistance  and  support  of  ADA  in  the  conduct  of  the  MI LCOM 
series  of  seminars  was  recognized  by  the  Chairman. 

KEYNOTE  ADDRESS 
DIRECTIONS  IN  MISSION-CRI I 1CAL 
COMPUTERS  AND  SOFTWARE 

Dr.  Edith  W.  Martin  Deputv  Undersecretary 
of  Defense  for  Research  and  Advanced  Technology 


DIRECTIONS  IN  MISSION-CRITICAL 
COMPUTERS  AND  SOFTWARE 


•  in  EM  WE  AM  TOME 


At  this  third  participation  in  the  Ml LCOM  series,  it  seems 
important  to  see  where  we  stand  in  the  mission-critical  resources 
area,  where  we  are  going,  wnaf  we  are  promising,  where  we  are  heading 
tomorrow,  and  what  we  want  to  be  able  to  say  we  nave  done  in  the  years 
to  come.  There  is  no  question  that  computers  ano  software  are 
critical  components  of  our  defense  strategy.  The  tremendous  growtn 
in  their  capabilities  has  enabled  us  to  implement  functions  in  military 
systems  that  only  a  few  years  earlier  were  either  infeasable  or  just 
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unaffordable.  We  now  nave  the  single  chip  CPUs  and  are  heading  toward 
the  single  chip  microcomputer.  We  have  software  measured  in  millions 
of  lines  and,  at  this  point,  some  of  it  is  starting  to  act  rather 
intelligent.  Technology  seeks  opportunities  and  rapidly  finds  them. 
That  sounds  like  a  wonderful  story  and  if  it  were  not  true  it  would  be 
difficult  believing  it  could  happen.  But  Babbage,  Turing  and  Von 
Neumann  would  truly  be  astounded  at  what  has  happened  with  their  ideas. 
Perhaps  not  Ada.  Yet  here  we  are  with  the  theme  of  problems  of  the 
future.  Why  problems?  We  are  growing  too  fast  and  at  different 
rates,  and  we  haven't  quite  figured  out  now  to  deal  with  it  -  the 
adolescence,  you  might  say,  because  it  means  we  are  increasing  the 
use  of  computers  for  better  software  than  hardware.  Software 
complexity  is  growing  exponentially  too  and  that  Is  unacceptable. 
Software  to  which  is  entrusted  much  of  the  responsibility  for  correct 
system  performance  may  just  be  a  disaster  that  is  waiting  to  happen. 
There  are  many  who  anticipate  that  and  are  trying  to  make  measures  to 
prevent  it.  How  do  we  deal  with  yesterday's  hardware  products?  lhey 
were  the  rage  and  now  they  are  not  made  anymore.  That  was  only  two 
years  ago  and  we  still  have  them  in  our  systems.  The  same  is  true  for 
yesterday's  standards. 

OSD  has  just  completed  a  study  that  supplements  the  report  on 
computer  technology  it  submitted  to  Congress  last  September.  T 
study  addresses  the  topics  listed  here. 


KEY  TOPICS 


•  SOFTWARE  RNTIATIVES 

•  MICROPROCESSOR  POLICY 

•  MARAOEMERT  OF  COWFUTER  SYSTEM  MTERFACES 

•  EVOUmOR  OF  CORREOT  COMPUTER  PRO  MAMS 

•  SECT  GERERATIOR  MRJTARY  COMPUTERS 


An  overview  of  this  work  will  be  presented  because  it  involves 
some  very  important  new  directions. 

Comprehension  of  software  problems  is  widely  shared  so  software 
problems  will  not  be  discussed. 
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SOFTWARE  INITIATIVES 


TMK-POOOO  SOltmOl  TO  THE  SOF1WAK  CM» 


•  mat 

•  wmiMi— wn~n~i - n 


The 
Software 
are  some 
fami 1  tar 


status ,  plans  ana  policy  with  respect  to  Adat  STARS  and  the 
Engineering  Institute  (SEI)  will  be  discussed  because  there 
new  things  OSO  has  done  with  which  the  community  should  be 


Ada* 


•  OX  STAADAAWZATlOi 

•  WTEMATMOAl  fTMDMMZATIM 

•  FSEE-WOMD  DEVaontEOTS 

•  0*0  Ml*  POUCY 

•  COMPILES  VAUMTNO  P  ACUITIES 

•  MfrSPOSSOSEO  AM*  SYSTEMS 


*  Mill 
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On  February  17,  1983,  Ada  became  an  ANSI  Standard.  OSD/DOD  is 
now  participating  in  international  standardization  activities  and  we 
expect  to  have  an  ISO  standard  in  1985.  That  is  extremely  important 
for  the  Defense  Department  because  it  is  the  first  step  in  the 
direction  of  system  interoperability.  OSD  responsible  officials  are 
very  pleased  with  the  progress  of  Ada.  There  are  now  over  forty 
developments  of  Ada  compilers  in  the  free  world.  These  are  sponsored 
by  government,  by  industry  and  by  academia.  OSD/DOD  intends  to 
capitalize  on  these  (developments)  and  accelerate  the  use  of  Ada.  On 
June,  10,  1983  OSD  issued  a  policy  that  mandates  the  use  of  Ada  in  all 
mission-critical  systems  that  start  Advance  Development  in  1984  -  that 
is  now  -  and  they  start  Full  Scale  Engineering  Development  after  July 
I,  1984.  There  has  been  a  lot  of  questions  on  whether  or  not  OSD  is 
serious  about  those  dates  and  you  can  be  assured  OSD  is  (serious  about 
them).  All  Ada  compilers  are  required  to  comply  with  M1LST0  1815.  To 
date,  three  systems  have  been  validated.  Validations  have  been 
conducted  at  the  lnsitute  for  Defense  Analysis  (IDA)  thus  far,  and, 
in  the  near  future  validations  will  be  conducted  by  th  language 
Control  Facility  at  Wr ight-Patterson  Air  Force  Base  and  by  the  GSA 
Federal  Software  Testing  Center  here  in  Washington.  So  OSD/DOD  is 
gearing  up  for  the  rest  of  those  forty  development  activities.  DOO 
has  been  sponsoring  Ada  activities  for  some  specific  military 
computers  -  SOF IECH  Ada  Language  System  (ALS),  support  of  Ada  for  the 
Army's  Military  Computer  Family  the  UYK-41  and  40  as  well  as  the 
Navy's  UKY-43  and  44.  Right  now  a  TELESOF1  Ada  System  will  be  used 
early  on  for  SUBACS.  It  will  target  to  the  MOTOROLA  68,000  and 
subsequently  to  the  UYK-44  computer.  1NIERMETR1CS  Ada  Integrated 
Environment  (A1E)  for  the  Air  Force  will  target  initially  to  the  IBM 
3/0:  Also  the  Air  Force  will  shortly  have  an  Ada  effort  underway  for 
M1LSTD  1750  computer. 


Ada*  (CONTINUED) 


•  COMMOI  APSE*  MTHFACE  SET-“CAIS" 

•  IMG- RAISE  POLICY  08  APSFi 

•  I8TERIM  POLICY  01  APSE1* 

•  EVALUATWI  OF  APSE'S 

•  A**  THAI  SPORT  ABILITY  HASDB00X 

•  JO  SYSTEMS  COMMITTED  TO  USE  A*» 
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The  Department  (of  Defense)  has  been  working  jointly  with 
Industry  to  develop  some  interface  standards  for  Ada  Programming 
Support  Environments  (APSE)  and  this  is  called  "CAIS".  Ihese 
standards  will  facilitate  the  transportability  of  software  tools 
across  APSEs  produced  by  different  companies.  CAIS  is  now  under 
public  review  and  we  expect  to  have  a  very  solid  standard  by  the  end 
of  this  year.  When  the  CAlb  Standard  is  established  and  the  APSEs  are 
modified  to  accommodate  it,  there  will  be  a  great  deal  of  flexibility 
in  the  choice  of  Ada  environments  that  would  be  used.  ObO/DOO  expects 
rapid  technological  growth  In  this  area. 

The  CAIS  will  allow  each  company  to  use  the  APSE  of  its  choice. 
Most  important  for  OSO/DOD  is  that  they  use  a  "ricn"  environment. 

This  is  a  good  example  of  where  standardization  at  the  right  level  can 
accelerate  rather  than  impede  the  use  of  new  technology.  OSD  policy 
is  to  support  this  approach  so  long  as  steps  are  taken  to  permit  the 
Government  to  transition  over  to  another  Ada  environment  when  required 
at  any  point  in  the  system  life  cycle.  Conformance  to  the  CAIS 
Interface  Standards  is  extremely  important  to  a  1 1  (in  the  community). 

Until  the  CAIS  is  implemented,  our  interim  policy  is  to  allow  the 
use  of  company-owned  environments  wnere  the  government  will  benefit 
and  where  the  means  are  provided  for  a  transition  to  the  government 
environment  -  USD  does  not  mean  government  owned  by  one  that  meets 
government  standards. 

OSD/DOD  also  has  an  effort  underway  to  evaluate  the  capabilities 
and  performance  of  various  APSEs. 

With  CAIS  taking  care  of  the  transported! I i ty  of  Ada-oriented 
software  tools  across  different  environments,  let  us  turn  to 
transportability  of  applications  software  across  military  computers 
with  different  ISAs.  To  address  this  problem  we  will  be  developing  an 
Ada  fransportabi 1 ity  Handbook.  It  will  contain  rules  to  be  followed 
in  the  use  of  Ada  that  will  enhance  the  potential  for 
transportability.  The  first  version  of  that  handbook  should  be 
available  by  the  end  of  this  year  (1984). 

Ada  will  have  a  tremendously  favorable  impact  on  the 
implementation  and  coding  phase  of  software  development  and  throughout 
the  evolutionary  life  cycle  of  software.  However,  with  software 
providing  an  increasingly  higher  percentage  of  functionality  in  a 
modern  weapon  system,  and  with  software  costs  continuing  to  skyrocket, 
there  are  some  opportunities  to  reap  greater  benefits. 

Let  us  turn  to  the  software  activities  other  than  coding  - 
software  requirements  definition,  architectural  desiqn,  detailed 
design,  integration  and  testing,  (hey  are  largely  manual  and 
extremely  labor  intensive  activities.  They  are  only  rarely  supported 
by  automated  labor  reducing  and  error  reducing  aids.  Our  new  STARS 
program  addresses  that  opportunity. 


•  -/- 


STARS 


•  omwruamEs  ktmo  *u> 

•  2*J »*»WMOinuoE  ■creases*  software 

PRODUCTIVITY 

•  OROERS-OF-HAGHTUDE  DECREASES  M  LATEST  DEFECTS 

•  FOCUS:  THE  AUTOMATED  SOFTWARE  "FACTORF  COSCEPT 


FY  04  is  STARS  first  year  and  we  are  pleased  to  say  that  we  do 
have  a  new  program  this  year.  The  goal  is  orders  of  magnitude 
increase  in  software  productivity  and  a  comparable  reduction  in  the 
number  of  software  defects  that  are  latent  in  our  weapon  systems. 
STARS  will  focus  on  the  automated  software  factory  concept  -  a 
coherent  and  integrated  system  of  computerized  software  tools  and 
re-usable  software  parts  or  building  blocks. 


STARS  (CONTINUED) 


•  All  MMEOSIORS  OF  SOFTWARE  WILL  RE  ADDRESSED 


•  DEW  START  FOR  FT  1114 

•  JOIST  PROORAM  OFFICE  SOW  DPERATMRAl 

•  DETAILED  MPIEMERTATWB  PUS  IEISG  REALIZED 
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All  of  the  dimensions  of  software  activities  will  be  addressed 
including  technical,  project  management  and  software  acquisition 
issues.  STARS  will  also  build  on  useable  libraries  or  modules 
applicable  across  a  wide  range  of  functional  areas  such  as  navigation, 
intelligence  and  communications.  The  versions  of  the  automated 
software  factory  will  be  used  throughout  the  Services,  the  Defense 
Agencies  and  hopeful ly  through  Industry.  STARS  addresses  Oerense 
needs  which  are  pushing  the  software  capability  of  the  Nation  beyond 
its  present  limits.  It  also  provides  a  much  needed  national  focus  to 
retain  our  world  leadership  in  this  critical  technology  -  a  leadership 
that  is  now  seriously  threatened  by  at  least  four  projects  outside  of 
the  U.S.  One  may  disagree  with  Frank  Press  in  this  regard.  I he 
challenge  is  real  and  we  would  be  fooling  ourselves  if  we  feel  that 
we  do  not  have  tremendous  competition.  We  do,  and  the  time  to  address 
that  competition  is  right  now.  The  time  we  have  available  to  solve 
the  problem  is  three  years.  We  can  solve  the  problem  in  three  years 
or  resign  ourselves  to  be  second  or  third,  ihe  problem  is  real;  the 
challenge  is  great;  the  opportunities  are  great.  If  we  want  to  take 

advantage  of  the  opportunities  we  had  better  get  busy.  (Top 

management)  cannot  sit  around  board  rooms  heming  and  hawing  and 
deliberating  what  is  going  to  be  done  next  year.  They  should  think 
about  what  they  are  going  to  do  this  year.  Each  of  the  (competitive) 
efforts  that  is  underway  right  now  is  in  some  ways  more  mature  than 

our  own.  We  did  a  fine  job  of  enunciating  the  software  problem,  we 

have  had  a  lot  of  dialogue  in  discussing  the  software  problem,  we  have 
outlined  a  program  but  there  are  others  who  are  begining  to  address 
the  issues.  They  have  contracts  in  place  and  efforts  in  place  and 
whereas  they  may  not  be  quite  as  broad  as  ours,  they  are  making 
inroads  in  various  aspects  of  the  problem.  It  behooves  us  to  take 
heed.  In  the  case  of  the  Japanese,  they  have  the  first  approximation, 
at  least,  of  the  end  result  of  our  STARS  program.  The  reason  for 
saying  that  is  to  let  the  community  know  that  what  OSD  is  proposing 
here  in  not  "blue  sky"  and  that  tne  competition  is  not  miles  behind. 

It  is  at  our  sides  and  unless  we  are  serious  about  it  we  should  be 
prepared  to  lose. 

The  third  segment  of  our  software  initiative  is  the  Software 
Eng i neer i ng  1 nst i tute  ( SE I ) . 


SOFTWARE  ENGINEERING  INSTITUTE 
(SEI) 


•  MHO  AOVABCES  W  TECHB0106T  AM  NT  CMSSMQ 
BRIDGE  MTO  PRACTICE 

•  JOIRT  TAM  FORCE  AN  BUIE-MMOR  FAREL 


•  HHSSHM:  ACCELERATE  THE  TRAUITIN  OF  EMERSW6 

SOFTWARE  TECHROLOGT  WTO  USE  OR  MtSSlOB- 
CRITICAL  SYSTEMS 

•  ROT  A  RESEARCH  OR  TEACHWG  NSTTTUTE 
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Software  technology  has  been  advancing  very  rapidly.  A  broad 
technical  foundation  for  software  engineering  exists  and  continues  to 
grow.  That  is  all  well  and  good.  However,  for  a  variety  of  reasons, 
most  of  the  new  technology  has  not  crossed  the  bridge  into  widespread 
practice.  There  is  very  uneven  use  of  good  tools  and  good  concepts. 
There  are  many  research  results  and  feasibility  studies  that  are 
sitting  on  the  shelf  or  being  used  by  others  rather  than  ourselves. 

This  situation  was  first  addressed  in  early  1983  by  a  task  force 
which  proposed  the  creation  of  a  Software  Engineering  Institute  to 
tackle  the  problem  of  technology  transition  in  the  software  area. 

This  past  summer  (1983)  OSD  had  the  matter  studied  by  an  industry  and 
academia  panel  under  the  auspices  of  IDA  and  they  recommended  very 
strongly  that  we  move  very,  very  quickly  to  establish  the  SEI. 

The  SEI  will  not  be  a  research  or  teaching  institute  but  an 
organization  of  world  class  software  experts  dedicated  to  accelerating 
the  transition  or  the  emergence  of  software  technology  into  use  in  our 
defense  systems.  The  primary  mechanism  for  this  acceleration  will  be 
automated  software  and  the  use  of  the  "software  factory"  concept. 


SOFTWARE  ENGINEERING  INSTITUTE 
(SEI)  (CONTINUED) 


•  in  PR06RJUM  BL0KHT  ■  FT  1MC  MIMCT 

•  PIM  TO  ESTMUSM  RERf  KK  (LB,  URC8U  LM.  WTRE, 
AEMSMCQ 

•  FORMAl  MMCMHOS  WITH  HAMM  BWVBttfTT  ■  THE 

nos 

•  SELECTOR  PROCESS  MOOT  TO  STMT 

•  JEUCTIOR  PURRED  FOR  SHURB  IN4 


The  SEI  is  now  in  the  FY  198b  Budget.  That,  in  itself,  fs  an 
accomplishment.  Our  plan  is  to  establish  a  new  FCRC  along  the  lines 
of  MIT's  Lincoln  Laboratory,  Mitre  Corporation  or  Aerospace 
Corporation.  OSD  will  require  that  the  SEI  be  linked  with  one  of  the 
top  universities  in  the  field.  Initially,  that  will  probably  be  a 
central  focus.  It  is  intended  that  in  the  future  there  will  be 
centers  of  excellence  that  serve  in  a  satellite  fashion  in 
coordination  with  that  central  SEI.  OSD  final  planning  for  the  SEI 
will  be  completed  by  the  end  of  this  month  (January  1984)  and  we  will 
shortly  start  the  selection  part  of  encouraging  applications  from 
interested  parties.  It  is  planned  to  announce  the  location  of  the  SEI 
i n  the  spr i ng  (1 984 ) . 
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MICROPROCESSOR  POLICY 


•  ADMESSES  LOWEW  OF  COMPVTNM  SPECTRIN 


•  BASIS  FOR  POLICY 


lurning  to  hardware,  there  has  been  much  confusion  about  the  use 
of  microprocessors  vis-a-vis  standard  computers.  Micros  have  all 
kinds  of  different  instruction  sets.  Should  waivers  be  granted  for 
their  use?  The  area,  up  until  this  point,  has  received  benign 
neglect.  Designers  and  managers  were  never  sure  if  they  eventually 
were  going  to  get  their  wrist  slapped  for  using  them.  OSO  developed  a 
policy  of  this  area  and  it  is  contained  in  the  OSD  study  report.  This 
policy  recognizes  the  important  differences  between  the  micro  class 
where  the  CPUs  on  a  chip  or  complementary  chip  sets  all  of  which  can 
be  deeply  embedded  in  the  system  almost  to  the  point  one  hardly  knows 
that  it  is  there.  The  more  powerful  stand-along  computer  is  in  its 
seif  contained  chassis  -  a  part  of  the  difference  is  physical.  There 
are  other  important  differences.  First,  we  find  competing  suppliers 
for  each  chip.  Second,  prices  are  extremely  attractive  due  to  their 
high  production  volume.  Third,  the  usual  placement  of  micro  chip 
sets  on  circuit  boards  that  tend  to  be  system-unique  does  not  permit 
intersystem  logistics  commonality  that  we  might  have  with  stand-alone 
computers.  Fourth,  in  comparison  with  stand  alone  high  capacity 
computers,  micro  applications  do  not  tend  to  be  as  software  intense. 
This  last  point  relates  to  the  instruction  set  issue. 


MICROPROCESSOR  POLICY 
(CONTINUED) 


•  THE  DEFAAT1IEU  ERC8UU8ES  THE  BSE  OF  C8NM90AUT 
AVAILABLE  WCROPMCESSMS  THAT  MKT  THE  FOUOWMS 
REOUMEMEITS: 

•  MP  OVMKJTT  MDR 

•  UFHWU  CUT  uwcmuw 


Based  on  that  distinction,  OSD  policy  will  be  to  encourage  the 
use  of  commercially  available  micros  where  it  makes  sense  from  a 
systems  engineering  view  point  to  use  them.  OSD  requires,  however, 
that  several  conditions  be  met.  First,  they  must  be  programmed  in 
Ada.  Second,  they  must  be  cost  effective  over  the  life  cycle.  We  do 
not  want  obsolete  micros,  and  special  runs  just  for  DOD.  Third,  they 
must  be  suitable  for  use  in  the  military  environment  to  be  encountered 
in  operational  use.  That  may  mean  that  they  do  not  need  all  of  the 
MILSPEC  requirements,  but  a  sub-set.  Fourth,  multiple  competing 
suppliers  must  exist  for  each  chip.  For  the  long  term,  micros  used  in 
defense  systems  have  to  comply  with  the  interfaces  that  will  be 
established  through  the  efforts  of  government  and  industry  working 
groups . 


MANAGEMENT  OF  MISSION-CONTROL 
COMPUTER  SYSTEM  INTERFACES 


•  THE  COMPUTER  IS  ROT  JUST  MOTHER  SUBSYSTEM  BUT 
PROVIDES  THE  BASIS  FOR  IBTEERATIOH  OF  ESSEBTIAUT 
AU  OTHER  SUBSYSTEMS 

•  URCOBTROUEO  PROUFERATMB  OF  IBTERFACES  TO 
COMPUTER  SYSTEMS  IS  AB  HRPEMMERT  TO  THE 
IRTE6RATI0H  FURCTIOB  ABO  UBRECESSAMIY  COMPUCATES 
SYSTEM  OEVHOPBKBT  ABO  EVOUITIOB 

•  0(0  MUST  M ABASE  THOSE  IBTERFACES  THAT  ARE 
IMPORT  ART  TO  THE  IHTEBRATNR  FURCTIOB 

•  COMMOB  IBTERFACES  WIU  FACJUTATE  IBTEROPERABIUTY 
ABO  REUSE  OF  HARDWARE  ABO  SOFTWARE 


Here  Is  where  we  obtain  the  delicate  balance  between  the  benefits 
of  new  technology  and  the  benefits  of  standardization.  Managing  these 
interfaces  properly  is  going  to  be  an  extremely  important  task  because 
the  computer  and  its  software  provide  the  basis  for  system 
integration.  It  is  not  just  another  subsystem  plugged  into  a  major 
system  but  one  that  provides  the  glue  for  joining  subsystems  into  a 
cohesive  system. 

Uncontrolled  proliferation  of  Interfaces  is  guaranteed  to 
complicate  the  processes  of  system  development  and  system  evolution. 

On  the  other  hand,  proper  management  of  these  interfaces  will 
facilitate  interoperability  and  effective  reuse  of  hardware  and 
software. 


COMPUTER  SYSTEM  INTERFACES 
IMPORTANT  TO  DoD 


•  HHTMCTKM  SET  ARCHITECTURES 

•  0KRATM8  SYSTEM  IRTEAFACES 

•  COMPUTER  PERIPHERAL  MTERF  ACES 

•  SYSTEM  RUSES 

•  LUCRE  ARB  WIDE-AREA  RCTWON  MTERf  ACES 

•  AUTOMATED  SOFTWARE  “FACTORY"  MTERf  ACES 


This  is  a  representative  list  of  interfaces  that  are  important  to 
DOD.  Others  not  on  here  may  be  important.  The  list,  no  aoubt,  will 
change  over  time. 
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INSTRUCTION  SET  ARCHITECTURE 


•  D1FFEKRT  ISA's  IMPEDE  TRAR  SPORT  AMUTT  OE  RIM-TWE 
SOFTWARE 

•  AM*  TRAISPORTABIUTT  HAROROM  WU  HELP  IDT  WU 
■OT  BE  A  PARACEA 

•  DsM  BBBMX  WAS  DsWs  BWIUi  APPROACH  TO  THE 
MAHAGEHEHT  OF  THIS  MTERFAd 

•  A  SUPERIOR  1016- TERM  AITERIATTVE  HAS  BOH  DEVELOPED 
MO  DsDI  MBRJX  HAS  OEM  ABMOOHEO 

•  FUTURE  DMECTMH  OF  ISffs  OOCERTAM 

•  mh  mat 

•  MHTMMUa? 

•  FUTURE  DsO  APPROACH  VIA  A  COOPERATIVE  DOVER* 
■EBTIIBDUSTRV  EFFORT 


The  subject  that  generated  the  greatest  amount  of  controversy  - 
instruction  set  architecture  -will  now  be  addressed.  It  was 
established  in  the  OSO  report  to  Congress  that  different  ISAs,  even 
with  Ada,  is  an  impediment  to  transportability. 

The  Ada  Transportability  Handbook  will  ease  this  problem,  but  do 
not  expect  it  to  be  a  panacea.  The  OSD/DOD's  approach  to  this  problem 
was  Instruction  5000. 5X.  OSO  now  hopes  it  has  a  better  approach. 

OSD  is  looking  at  where  the  instruction  sets  are  going.  It  is  an 
area  where  there  is  a  great  deal  of  technical  activity  at  this  time. 
Eight  years  ago  when  OSD  started  to  discuss  instruction  set 
architecture  there  was  not  a  lot  happening  in  the  shift  of  ISAs.  They 
could  be  lumped  into  a  number  of  pretty  straight  forward  categories. 
There  were  not  major  step  changes  in  ISAs  from  year  to  year  or  month 
to  month.  That  is  not  the  case  right  now.  One  segment  of  the 


community  believes  that  the  higher  level  instruction  sets  should  be 
used  -  ones  with  more  compound  instructions.  Another  segment  believes 
that  the  next  generation  ISAs  should  be  simpler  than  those  we  are 
using  today.  There  is  also  a  parallel  consideration  and  a 
considerable  amount  of  work  underway  on  approaches  for  very  highly 
parallel  ISAs. 

Perhaps  the  only  thing  agreed  upon  is  the  need  to  distill  a 
future  direction  from  among  the  various  approaches  now  being 
investigated.  OSO  strategy  is  to  treat  ISA  not  as  a  separate  issue, 
but  in  the  context  of  a  total  computer  system  interface  approachy. 

This  involves  a  cooperative  effort  between  government  and  industry. 


COMPUTER  SYSTEMS  INTERFACE 
WORKING  GROUP  (CSIWG) 


s  services.  wo.  beferse  mooes 

•  DEVELOP  IMO- TERM  APPROACH  TO  AU  WTEtfACEf 
tTAIT  ACROSS  WMRWXRmCAl  SYSTEMS 


- TO  ESTMUSM  A  PARALLEL 

_ —  »TTR  a  um  to  batwral  stammrs 

ACTTVTTWS 

•  CSIW6  MU  IE  ESTABLISHED  ■  HARM  ISM 


This  March  (1984)  OSD/DOO  will  form  a  Computer  Systems  Interface 
Working  Group  with  the  mission  to  develop  a  long  term  approach  to 
interfaces  of  the  type  discussed  above.  The  goal  of  this  effort  is  to 
facilitate  interoperability  and  re-use  of  equipments  and  software 
produced  from  different  programs  and  different  companies,  or  even  by 
the  same  company.  OSO  encourages  Industry  to  work  with  it  and 
establish  a  group  that  functions  in  parallel  with  the  OSO/DOO  group. 

We  also  want  to  link  this  effort  to  national  standards  activities 
because  many  of  the  interfaces  could  be  identical  to  those  used  in  the 
future  commercial  mainstream  activities.  Were  OSO/DOO  needs  to 
depart,  because  of  its  requirements  being  unique,  it  will  do  so. 

Where  OSD/DOO  has  an  opportunity  to  go  with  the  community  at  large,  it 
certainly  will  follow  that  course. 
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EVOLUTION  OF  CURRENT 
COMPUTER  PROGRAMS 


•  mi  services  mu  use  mh-std-itm  aid  mustn-imj 


•  ARMY'S  MUTANT  COMPUTER  FAMILY  PMMAAM 


m  MmiM  iw  wni  mau 


•  RVt-VtM  FMMCT—  ITMT  HMT  NMTH  «  1MT 


We  will  discuss  where  our  current  computer  programs  are  going  and 
then  come  back  to  the  OSD/DOO  plan  to  use  the  interface  work  in  the 
next  generation  of  military  computers.  A  proposal  on  the  acquisition 
of  DOD  next  generation  of  products  will  be  presented.  It  will  be  of 
interest  to  industry  because  it  is  significantly  different  from  the 
first  OSD/DOD  approach.  OSD  long  range  plan  is  to  have  production 
quality  next  generation  computers  in  qualification  testing  in  1991 
which  is  not  far  away.  DOU  present  computer  programs  will  see 
production  starts  continuing  up  to  1991  or  1992  depending  on  the 
program.  New  starts  beyond  that  time  will  go  with  the  next 
generation.  All  of  OSO/DOD  current  program  as  well  as  next  generation 
systems  will  support  the  use  of  Ada. 

All  of  the  Services  will  be  using  MILSTD  1/50  and  M1LST0  1862 
iSAs.  1750  will  be  used  for  the  Air  force  avionics.  It  will  be  used 
only  at  the  chip  set  level  by  the  Navy  and  by  the  Army  for  16-bit 
applications.  Ihe  number  of  different  hardware  types  will  be  tightly 
controlled  by  the  Army,  which  will  not  develop  1/50  computers  but  will 
build  on  those  already  available  through  the  Air  Force  effort.  1862 
will  be  used  in  the  Army's  MCt  program,  by  the  Navy  in  its  single 
board  computer  effort  and  by  the  Air  force  in  32-bit  applications  when 
computers  come  available.  Ihe  Army's  MCF  program  will  award  Full 
Scale  Engineering  Development  Contracts  shortly  -  two  competing 
contracts  -  and  ending  with  two  competing  production  contracts. 

Later,  additional  producers  may  be  included  in  the  competition. 
Competitors  computers  will  be  form  fit  and  function  interchangeable 
but  users  are  cautioned  that  the  validation  of  the  interchangeability 
will  have  to  be  made  an  integral  part  of  the  system  design  process. 
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EVOLUTION  OF  CURRENT  COMPUTER 
PROGRAMS  (CONTINUED) 


•  MVTS  MOTMJ  MM  MVTK44  PMMMM 


•  mub  wmH  mi  Mmi 


The  Navy's  AN/UYK-43  and  44  programs  are  in  the  early  phases  of 
production.  Production  will  continue  for  new  starts  of  the  43  through 
1991  and  for  new  starts  for  the  44  through  1990.  Production  will 
continue  after  these  points  to  support  maintenance  up  to  the  point 
where  buy-out  can  be  made. 


EVOLUTION  OF  CURRENT  COMPUTER 
PROGRAMS  (CONTINUED) 


•  Mm  wmii  i 

•  IMMCTW  ST AITO  ■  TIN 


•  M  FMCE  CMMTfS  POUCT 
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The  Navy's  standard  airborne  computer,  the  AYK-14,  is  now  in 
production  and  will  continue  to  be  produced  for  new  starts  through 
1989.  Last  month  a  contract  was  awarded  to  Sperry  for  second  sourcing 
of  the  AYK-14  on  a  bui Id-to-pri nt  basis.  Ihe  competition  that  will 
exist  between  Sperry  and  COC  is  important  in  what  OSD  perceives  to  be 
a  large  production  that  is  planned. 

The  Air  Force  does  not  have  a  standard  inter-system  hardware 
program  because  of  the  way  it  supports  its  systems.  The  Air  Forces 
Ada,  1750  and  1862  approaches  have  been  discussed  above. 


NEXT  GENERATION  MILITARY 
COMPUTERS 


•  EXTCID  MCMPMCtSSOR  POIICT  IV 
MICBOCOMPUTCAOUACIIIP 

•  BASE  I  EXT  GEBEAATHM  Hi  CBMPUTtB  SYSTEMS 
MTEBFACE  ACTIVITIES 

•  EICO  USAGE  IS  DUSTS  Y  TIT  PB000CE  COMPETITIVE  SHUT  AST 
COMPUnKS  MEETM6  JOISTIY  DEVELOPED  FOSSMTT 

nncnofl  speoficatiois 

•  QUAUFT  MULTIPLE  COMPASIES  AS  CBtTIFIED  SUPPLIED* 
FOS  SNUTASY  COMPUTESS 

•  sen  OESESATIOS  COMPUTESS  MSI  BE  SEEDED  IS  1M2 

•  COMPLETE  MTEBFACE  EFFOSTS  PBIOB  TO  NHMII7 

•  COSTISUE  SOESCE  ASO  TECHS0L06Y  EFFOSTS  TO 
MAISTAJS  UX  STSES6TH  ASD  LEAOEBSHtP 


Regarding  next  generation  systems  where  micros  are  concerned,  OSD 
expects  to  see  entire  microcomputers  on  single  chips  and  sees  no 
reason  not  to  extend  the  micro  policy  discussed  above  to  these 
devices,  with  the  condition  that  they  comply  with  the  newly  developed 
interfaces. 

As  for  the  more  powerful  next  generation  stand-along  computers, 
they  will  be  based  on  this  same  interface  work.  OSD  encourages 
industry  to  produce  competitive  military  computers  meeting  jointly 
developed  interface  and  form,  fit  and  function  specifications. 

OSD/DOD  will  posture  inself  to  qualify  industry  sponsored  products  for 
use  in  (U.S.)  military-critical  systems. 

The  interface  and  form,  fit  and  function  efforts  should  be 
completed  prior  to  mid- 1 987  in  order  to  obtain  fully  approved 
production  units  in  1992. 
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OSD/OOD  will  continue  its  technology  base  work  in  this  important 
area,  and  will  conduct  development  work  in  support  of  the  interface 
and  form,  fit  and  function  activities.  This  is  an  important  new 
approach  and  OSD/OOD  welcomes  Industry  to  join  it  and  to  help  make 
this  approach  work. 

In  summary,  we  are  talking  about  some  new  and  exciting  directions 
in  military  computers.  It  is  a  challenge  that  promises  some  very  high 
pay  offs.  It  will  not  be  easy.  OSO/DOD  and  Industry  must  work 
together  because  the  success  of  each  is  shared  by  the  other. 

In  response  to  questions,  the  following  points  were  made: 

- Or.  Lieblein's  and  Mr.  Maynard's  offices  will  be  putting  the 

Computer  Systems  Interface  Working  Group  together  within  the 
government.  OSD  may  look  at  a  group  of  several  industry  or¬ 
ganizations  as  a  vehicle  for  industry  participation.  For 
individuals  or  companies  not  members  of  any  included  industry 
organization,  some  mechanisms  will  be  provided  for  affiliation 
with  some  of  the  advisory  activities  thus  established.  The 
entire  area  of  industry  participation  will  be  publicized,  most 
likely  through  CBD. 

- Discussions  have  been  held  with  companies  doing  new  work  in 

expert  systems  and  artificial  intelligence  using  LISP  and 
PROLOG  and  their  assessment  is  that  Ada  is  very  well  qualified 
to  handle  commands  and  processing  required  for  expert  systems  and 
would  not  make  the  implementation  of  such  systems  difficult. 

None  have  been  programmed  in  Ada.  Unless  there  is  a  true 
penalty,  OSD  expects  to  specify  Ada  for  expert  systems.  If  in 
the  future  a  much  superior  (to  Ada)  artificial  intelligence  lan¬ 
guage  appears,  OSD  will  use  it. 
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SESSION  I 


PROBLEMS  BALING  lHt  SERVICES  IN  IhE  f  U I  LIKE 


l 

Chairman:  Mr.  Joseph  Grosson 

Assistant  Deputy  Commander 
for  Acquisition.  Naval  Sea  Systems  Command 

Pane i i sts/Speakers : 

Commodore  Stuart  Platt  (SC).  Usn 
Competition  Advocate,  U.S.  Navy 


Brigadier  General  Alan  B.  Salisbury  USA 
Joint  Program  Manaqer.  Joint  I  act i cal 
I- us  ion  Program  and  All  Source  Analysis  System 
DCS. OPS,  HU  U.S.  Army 

Rear  Admirai  Wayne  £.  Meyer,  usn 
Deputy  Commander, 

Naval  Sea  Systems  Command 


Brigadier  Jonn  Paul  Hyde,  usAf  . 

UC/S  Communications.  £  lectromcs,  ana  Computer 
Resources,  USAf-  Space  Command  and  N.  American 
Aerospace  uerense  Command;  Cniet,  Systems 
integration  Office.  Space  command;  and 
Commander  Space  Communications  ui vision. 

Air  force  Communication  Command 


Panelists:  Col.  Harold  Archibald,  USA 

Chief,  Battlefield  Automarion  Division 
H/U  UARCOh 

Mr.  Norman  Brown 
Special  Assistant  to  tne 
Competition  Advocate  General.  U.S.  Navy 
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I NTRODUtl I  ON 


Mr.  Grosson  opened  the  session  with  the  projection  that  if  907.  or 
scientists  and  engineers  who  have  ever  lived  are  alive  today,  we  have 
not  even  Degun  an  upswing  on  the  "technology  curve".  This  exponential 
growth  we  are  seeing  raises  questions.  Does  the  rate  of  advance 
exceed  our  ability  to  anticipate,  plan,  design,  develop,  procure  and 
use?  Are  we  moving  too  fast  or  too  slow?  Looking  at,  hopefully, 
unlikely  extremes  of  this  question  suppose  we  are  moving  too  fast? 
Because  of  the  plethora  of  decisions  required  of  the  field  commander, 
necessary  reaction  time  increases  reliance  on  machines.  Does  this 
pose  the  danger  of  losing  control  of  tactical  decision  making? 
buppose  we  are  moving  too  slow.  Does  this  pose  the  danger  of  our 
falling  behind  in  our  ability  to  handle  tne  obvious  threats  and,  more 
impor rant  1 y,  we  may  not  be  able  to  handle  the  unknown  future  threats? 
Will  procurement  policies  artificially  force  us  in  the  wrong 
direction?  first,  by  requiring  too  much  competition  in  systems 
development  or  are  our  mandates  to  use  standards  overly  constraining? 
What  about  automation?  What  is  the  correct  man-machine  interface? 

How  far  do  we  dare  remove  the  man  from  tne  system?  Can  we  control  tne 
dyanmics  of  this  technology  by  deciding  how  far  and  how  fast  we  dare 
to  go  in  such  areas  as  decision  making,  command  control  and 
communications,  target  engagement  or  reliance  on  artificial 
inte i I igence? 


Commodore  Piatt 


This  discussion  will  embrace  four 
in  our  economy;  the  Navy's  thrust  for 
rights  and  some  problems  in  that  area; 
rights . 


points  - 
ncreased 
and  some 


changes  we  are  seeing 
competition;  data 
Navy  actions  in  data 


Changes  in  our  economy  include  rev i ta 1 1 zat ion  in  general  and  in 
smoke  stack  America,  redirection  in  most  major  businesses,  interest 
rates  more  under  control,  low  wholesale  price  index  increases,  and 
increased  capital  investment  in  industry.  Additional  changes  included 
re-evaluation  of  their  own  portfolio  managements  and  business  thrusts 
by  conglomerates,  additional  companies  coming  into  the  defense 
business,  inordinate  impact  of  Wall  Street  analysts  on  the  thinking  of 
major  companies,  and  relearning  and  reuse  of  strategic  planning.  Ihe 
Navy  is  trying  to  work  its  problems  at  the  lowest  levels  -  tne  project 
levels  -  and  it  is  appearing  that  is  where  they  can  be  worked  best  on 
both  sides  of  the  table.  Government  and  industry  are  victims  of  the 
same  data  base  using  the  same  numbers  and  often  coming  up  with 
different  answers.  Deregulation  is  another  form  of  competition  and  it 
is  being  pushed  by  companies  and  in  many  sectors  of  our  economy  with 
some  benefits  to  consumers,  concerning  competition,  the  Japanese 
appear  to  read  our  books  listed  to  what  we  say,  believe  we  actually  do 
it  and  then  go  home  and  do  it.  We  are  a  country  and  nave  a  Navy  that 
operates  well  in  crisis  and  it  is  managing  a  lot  of  problems  now. 


In  fostering  competition, 
strategy  but,  hopefully,  to  do 
directed  executive  agencies  to 


the  Navy  is  not  trying  for  a  minimum 
what  seems  best,  the  President  has 
seek  more  competition.  The  Congress 
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spelled  out  the  desire  for  more  competition  in  the  FY  1984  Oetense 
Appropr iat ion  Act.  The  Secretary  of  Defense  has  directed  (more 
competition)  and  the  Secretary  of  the  Navy  nas  instructed  top 
executives  to  seek  more  competition.  Our  strategy  is  to  try  to  oo 
more  (to  foster  competition).  We  are  working  on  the  action  or  how  to 
do  it  -  intelligently  -  not  whether  or  not  it  is  good.  Inflexibility 
to  change  is  not  something  the  world  rests  with.  In  all  dynamic, 
moving  systems  -  technical,  social  or  otherwise  -  chanqe  takes  places 
as  time  moves  on. 

I  he  Navy  thrust  for  increased  competition  comes  at  a  time  of 
drastic  events  in  the  shipbuilding  industry,  in  aerosace,  fifty 
percent  or  the  Dusiness  is  attributable  to  military  requirements. 
Commercial  aircraft  sales  are  declining  since  1980.  Forecasts  for 
shipbuilding  and  aerospace  make  military  market  segments  much  more 
dominant.  In  1982  world  trade  dropped  to  the  lowest  level  since 
World  War  II.  I  he  number  of  ships  in  the  world  trading  fleet  has 
declined  for  the  first  time  in  over  thirty  years.  Very  few  deep  draft 
commercial  ships  are  ordered  in  this  country,  ihus,  in  some 
industries  the  military  is  becoming  the  demand  curve,  corporate 
management  at  top  levels  and  the  Navy  are  learning  to  work  with  it. 
Many  people  reel  that  the  defense  computer  business  is 
counter-cyclical  and  that  seems  silly,  the  Navy  market  for  ships  and 
shipboard  systems  seems  bright  into  the  years  to  come  and  a  major  part 
of  that  business  for  the  foreseeable  future.  When  the  Navy  gets 
favorable  buys  it  (still)  wants  to  keep  its  options  open  for 
(follow-on)  buys.  I  he  Navy's  best  interest  is  served  bv  industry 
being  smart  sellers.  A  not-informed  industry  and  a  not-intel I lgent 
contracting  business  community  is  the  last  thinq  we  need.  (Jne  of  the 
best  things  that  can  happen  from  meeting  like  this  is  that  the  (navy 
representatives)  tell  industry  what  thev  think.  industrv  likes  it  or 
it  doesn't  and  may  even  get  it  changeo.  Most  of  the  time  the  Navy 
gets  hurt  is  from  industry's  uninformed,  very  lofty  and  treacherous 
business  ventures. 

In  many  cases,  the  government  cannot  compete  where  it  seeks  more 
competition  because  of  data  rights.  I  fie  Navy  is  looking  at  how 
extensive  that  (restriction)  is  and  what  rue  Navy  wants  to  do  about 
it.  It  is  very  important  for  the  Navy  to  get  trie  data  it  needs  and 
has  paid  for.  The  contract  for  procurement  of  U.b.b.  MUNITOF?  (circa 
I8b2)  follow-ons  was  a  case  wnere  part  was  sole  source  and  the 
remainder  by  competitors  who  paid  a  fee  to  the  original  designer  tor 
drawings.  It  is  very  important  for  the  Navy  to  make  sure  it  get  the 
data  it  needs  and  has  paid  for.  As  Defense  budgets  increase.  Navy 
contract  professionals  are  told  to  review  trie  data  rights  issues  in 
formulating  new  contracts,  as  change  orders  are  issued  don't  give  up 
the  rights  the  Navy  already  owns  and  challenge  the  limited  rights 
stamps  that  go  on  many  drawings  when  there  does  not  appear  to  be  a 
reason  (for  it).  Data  rights  issues  nave  been  pursued  by  the  Navy  on 
a  case-by-case  basis.  The  other  services  may  look  at  it  somewnat 
differently,  but  it  all  seems  to  be  the  same  problem,  if  the  other 
services  have  a  better  way  to  do  it,  the  Navy  will  join  up.  On  a 
case-by-case  basis,  examples  are:  Litton  providing  listings  of  4,500 
inertial  navigation  system  parts  the  Navy  couldn't  buy  directly 
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because  of  proprietary  rights;  Sikorsky  has  agreed  to  thetr  licensee 
selling  directly  to  Inventory  Control  Points;p  Pratt  and  Whitney  has 
agreed  to  the  sale  of  aircraft  engine  parts  and  items  they  don't  make 
themselves  directly  to  Navy  Supply  Centers;  Sperry  nas  lifted  the 
legends  from  their  drawings  with  respect  to  Navy  work  and  there  are 
many  other  examples.  The  Navy  is  telling  all  of  its  contracting 
people  what  industry  tells  us  in  tnese  letters,  so  they  know  and  can 
help  implement  it.  A  point  for  encouragement  is  the  resDonsIve 
attempt  to  try  to  resolve  some  of  the  "horror"  stories  we  hear  about. 
Some  of  the  stories  we  hear  today  on  spare  parts  are  intensely  and 
fieguetly  discussed  and  are  painful.  Some  good  is  coming  of  it.  A 
lot  of  industry  is  responding  as  they  see  it  and  trying  to  make  it 
easier  and  better  for  us  to  work  in  the  spare  parts  area. 

I  he  Navy  seeks  to  get  more  competitive  and  would  like  to  let  the 
marketplace  seek  competition.  The  Navy  is  trusting  senior  executives 
to  be  the  ones  to  do  it,  to  carry  it  out  and  to  make  it  work,  lhe 
Navy  is  very  aggressively  after  more  competition,  wants  to  do  it 
intelligently,  understands  there  are  some  programs  it  can't  (promote 
competition)  and  wishes  to  reserve  those  decisions  for  itself. 

Brigadier  General  Salisbury 

Ihis  presentation  is  a  perspective  from  the  fiosition  of  program 
manager  in  the  Army's  All  Source  Analysis  System  and  Joint  Tactical 
fusion  Programs.  This  is  not  a  policy  position  in  Army  computer 
matters.  It  is  rather  from  a  position  of  having  to  live  with  and 
implement  these  policies,  with  which  there  is,  happily,  complete 
agreement.  Ihis  presentation  is  not  as  spokesman  for  the  Army  but 
rather  personal  experiences  and  observations  based  on  a  former 
appearance  at  MIlCUM  and  as  program  manager  for  PIPS  and  I OSS  (now 
Maneuver  Control  System). 

from  a  Program  Manager's  viewpoint,  problems  of  the  future  divide 
into  development,  survi vabi I ity  and  supportabi 1 ity  problems. 

The  first  development  problem  is  acquisition  cycle  vs.  computer 
based  systems  which  are  nearly,  but  not  quite  incompatible,  lhe 
classical  acquisition  cycle  is  easily  within  V2  years.  The  technology 
half-life  is  around  two  years  today  for  major  semiconductor 
innovations  with  shorter  periods  for  some  "leaps  forward",  lhink  back 
eight  years  ago  to  I97S-76,  the  birth  of  the  microcomputer ,  and  how 
far  we  have  come  since  then.  How  can  we  compare  where  we  are  in  the 
latter  part  of  that  cycle  with  the  technology  input  of  eight  years 
ago?  To  put  perception  of  the  user  problems  in  focus,  take  VI  SI  CALC. 
How  could  a  top  executive  have  been  persuaded  eight  years  ago  that  in 
eight  years  he  could  have  a  VISICALC  desk  top  environment? 

Corresponding  to  the  problem  of  technology  half-life  there  is 
doctrinal  half-life.  There  are  measurable  changes  in  doctrine  which, 
although  not  as  rapid  as  technology  changes,  make  doctrinal  hal^-life 
much  less  than  the  acquisition  cycle.  Regarding  computers  in  u  1 ,  the 
program  manager  in  early  stages  must  have  tremendous  insight  to 
visualize  problems  and  requirements  eight  to  twelve  years  out  in  the 
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future.  Few  have  the  instgnt  to  accurately  forecast  thym;  ana 
organ i zat iona l  and  method  changes  as  well.  Ine  Army  is  going  to  a 
light  division  of  l(),0U0  troops  vs.  a  b.UUO  man  conventional  division 
with  a  communications  electronic  warfare  battalion,  lhe  light 
division  will  have  only  a  military  intelligence  company,  furtner , 
there  is  a  policy  half-life  incident  to  changing  administrations,  top 
military  leaders  etc.  with  accompanying  shifts  in  priorities.  The 
only  solutions  to  these  problems  of  the  program  manager  is 
evolutionary  development.  It  was  pioneered  successfully  in  the 
Manuever  Control  System  and  is  being  used  in  the  All  Source  Analysis 
System  today.  The  evolutionary  development  starts  with  minimum 
implementation  in  the  hands  of  trooos  so  as  to  evolve  the  definition 
with  the  user.  It  may  be  a  disappointment  in  not  solving  many  or  all 
problems  in  first  iteration.  It  avoids,  however,  tne  problems  of  a 
system  passing  the  test  of  the  Engineering  Development  Model  and  then, 
"falling  flat  on  its  face"  in  tne  hands  of  troops  to  whom  it  is 
deployed  because  original  reguirements  were  almost  "ivory  tower"  and 
many  changes  have  taken  place.  In  this  sense  it  is  a  sort  of 
Preplanned  Product  Improvement,  approach  -  starting  small,  usinq  much 
user  feedback  and  developing  in  increments.  Opportunities  for 
technology  insertion  are  open  all  aionq  the  wav  and  this  is  a 
tremendous  benefit,  it  will  be  possible  to  use  of f-the-sne I ve 
computers  in  the  initial  iteration  and  shift  to  militarized  ruggedized 
and/or  augmented  system  computers  in  later  iterations  which  will  also 
meet  expanding  requi rements. 


ihe  program  manager's  iob  is  qreatiy  eased  if  a  total  package  of 
computer  resources  with  ail  of  the  Development  and  support  tools  is 
ready  to  go  rather  than  to  have  to  "reinvent  ail  of  those  wheels". 

(he  laissez  faire  approach  has  not  served  tne  Army  wei 1  in  most  of  its 
program  because  the  pressure  to  go  for  tne  latest  development,  special 
purpose  or  otherwise,  requires  re  inversion  of  support,  training  ana 
logistics  fools  which  is  very  expensive. 


ihe  problem  as  we  move  into  more  standardization  is  properly 
balancing  competition  with  the  benefits  of  standard! zat ion.  me  MCK 
program  is  doing  this.  There  may,  nowever,  be  problems  as  MCF 
transitions  into  a  more  limited  supplier  environment,  but  they  appear 
to  be  manageable.  So  for  any  new  computer  offered  in  a  program  the 
program  manager  will  ask  tor  complete  documentation,  a  fui i  support 
environment  including  Ada,  a  total  Ada  programming  environment  and 
compatabi 1 ity  across  contractor  environments.  The  transition  to  Ada, 
standardizat ion  of  tools  and  configuration  control  across  multiple 
suppliers  is  a  nontrivial  problem. 


Survivability,  more  than  anything  else,  justifies  a 
standardization  approach.  It  is  one  thing  to  have  compatible 
processors,  perhaps  through  the  Ada  level,  and  another  thing  to  have 
interchangeable  processors  on  a  form,  fit  and  function  oasis. 

Visualize  (CH)  in  the  height  of  battle,  with  only  partial  logistic 
support,  and  the  Maneuver  Control  or  Intelligence  Computer  fails.  Ihe 
combat  unit  is  hard  pressed  to  continue  operating  with  what  is  on  hand 
and  a  combat  service  support  or  supply  computer  is  still  operating  Out. 
can  not  be  applied  to  the  manuever  control  or  intelligence  functions. 


-It- 


This  Isa  real  proolem.  If  downstream,  tne  benefits  of 
standardization  can  permit  stopping  computer  operations  for  service 
support  and  applying  that  computer  to  manuever  control  or 
intelligence,  the  payoff  will  be  tremendous.  It  is  of  no  comfort  to 
know  that  there  were  twenty  three  eligible  to  bid  on  the  computer 
that  failed. 

In  the  Army  today,  afrordabt lity  vs.  survi vabi I  tty  is  a  major 
dilemma  in  the  Army  today.  The  Maneuver  Control  System  recently  went 
through  ASARL  to  go  into  a  production  decision.  The  Tactical  Computer 
Terminal  and  the  Tactical  Computer  System  performed  in  superior 
fashion  and  met  every  imaginable  necessary  military  specification  out 
they  were  just  too  expensive  to  afford  equipping  the  Army  with  them. 
The  decision  was  to  buy  enough  to  meet  the  hard  core  requirements. 

Ihis  will  provide  a  back  bone  manuever  control  capability  throuahout 
the  tactical  forces  and  will  probably  be  complemented  oy  a 
non-developmental  terminal  that  can  be  made  compataole  and 
interoperable  with  the  developed  Manuever  Control  System  elements. 
There  survivability  will  be  traded  off.  If  the  Army  has  a  hard-core 
back-bone  system  if  knows  is  qomg  to  survive  under  any  operational 
exciqences,  where  additional  processors  and  terminals  for  other  staff 
elements  are  needed,  they  can  be  taken  from  the  commercial  world  and 
not  worry  about  (their)  survivability  so  much.  New  technology  is 
working  for  the  Army  in  this  area.  In  the  I act i cal  Combat  Service 
Support  area,  TCSS  System  under  the  computer  Systems  Command  is 
evaluating  three  competitive  systems.  They  are  standard,  commercial, 
off-the-shelf  (equipments) painted  0.1).  and  configured  perhaps  a  little 
uniquely  but  with  very  little  packaginq  change.  They  do  not  need  much 
upgrade  to  survive  reasonably  well  in  the  intelligence  or  maneuver 
control  area,  they  are  beinq  looked  at  as  possible  surrogate 
terminals  in  those  other  areas.  TtMPEsT  and  "shake,  rattle  and  roll" 
will  be  easier  and  cheaper  to  meet  with  the  new  technology  and 
packaging  leading  to  greater  survivability  of  off-the-shelf  equipment. 
Reduced  costs  may  allow  more  throw  away  or  radically  different 
ma  i ntenance  ph i I osoph i es . 

Considering  interoperability  vs.  integration,  it  is  one  thing  to 
have  systems  that  can  interoperate.  It  is  another  to  have  systems 
that  are  integrated  in  some  sense,  lo  i l lustrate,  consider  the 
display  to  operator  ratio.  If  an  operator  in  a  command  post  has  to 
interoperate  with  maneuver,  intelligence,  fire  support,  etc.  should  he 
have  three  different  terminals  in  front  of  him?  Ihe  laissez  fiare 
approach  says:  "absolutely  that  is  what  he  will  get  from  three 
different  contractors  under  three  different  programs".  Ihat  generates 
logistics,  training  and  affordadi I ity  problems,  but  a  rommon  standard 
type  terminal  that  can  interface  all  three  will  improve  those  factors 
for  the  Army. 

A  related  factor  is  the  integration  of  systems,  in  a  different 
sense,  with  distributed  data  bases.  Une  concept  is  to  continue  to 
develop  systems  in  a  vertical  fashion  -  one  project  manager  and  one 
requirements  community  looks  vertically  and  defines  what  is  needed  in 
its  operational  area  -  fire  support,  manuever,  combat  service  support, 
intelligence  etc.  I  hen  when  these  systems  are  all  put  together  there 
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are  major  problems  of  interoperability  ana  of  duplication  of  data  or 
data  cannot  be  exchanged  because  the  data  base  formats,  data  elements, 
data  dictionaries  are  all  different,  lhe  Army  is  now  taking  more 
horizontal  looks  across  systems  to  develop  horizontal  as  well  as 
vertical  integration.  It  cannot  be  assumed  that  there  is  just  one 
magical  interface  point  where  the  whole  intelligence  community 
interfaces  with  the  maneuver  community.  In  All  Source  Intelligence 
there  are  many  intelligence  dedicated  sensors  which  an  All  Source 
Analysis  System  would  process  information  from.  There  are  other 
systems  that  produce  good  information  that  can  be  used  in  the 
intelligence  area.  Fire  support  acquisition  radars,  for  example, 
provide  information  that  is  necessary  for  a  complete  intelligence 
picture.  Does  that  information  have  to  flow  all  the  way  up  to  tne 
fire  support  chain  to  a  control  computer,  then  to  a  control  compufei 
in  the  intelligence  chain  and  down  to  where  it  is  needed  or  are  these 
systems  to  oe  integrated  at  each  and  every  level  where  it  makes  sense 
to  do  so?  The  Army  is  moving  more  towards  the  latter,  from  a 
simplistic  to  a  more  complex  out  a  more  survivaoie  ana  more 
operationally  useful  environment. 

in  the  supportabi  I  i ty  area,  the  mari-macn  1  ne  interface  is  key  in 
terms  of  trai nabi I ity.  How  can  very  complex  systems  be  made  trainable 
to  the  average  soldier  in  a  reasonable  period  or  time  so  that  out  or  a 
two  year  nitch  the  Army  gets  a  lot  of  productive  time  out  of  him?  The 
related  problem  of  how  do  vou  make  complex  systems  simple  enough  for 
the  General  to  understand  as  well?  lhe  utility  of  the  computer 
processing  capability  can  be  applied  to  embedded  training  and 
simplification  of  the  operation  of  the  man-macnine  interface.  We  want 
to  be  able  to  move  a  Gl  trained  in  one  environment  to  another  without 
starting  from  ground  zero  on  training.  Field  support  of  software  is  a 
problem  doctrinal ly  in  the  standard  system  sense  the  Army  wants  to  be 
responsive  to  the  man  in  the  field  without  making  unique  changes  to 
impact  standard  world  wide  operation  with  training  and  doctrinal 
implications.  The  right  balance  must  be  struck  between  responsiveness 
to  the  man  in  the  field  and  maintaining  standards.  It  is  also  a 
problem  in  resources  to  provide  post  deployment  software  support.  It 
takes  support  groups  of  100  or  more  in  a  climate  of  increasing 
scarcity  of  personnel  with  required  skills  incident  to  strengthening 
divisions  up  front  and  reducing  the  support  elements.  Logistic 
support  over  the  long  term  is  especially  important  in  view  of  the 
short  technological  life  ana  examples  of  unique  support  of  spares 
production  for  older  equipments.  The  support  of  the  new  high 
technology  equipment  has  to  be  worked  out  for  the  life  cycle  of  that 
equipment  of  10  to  20  years,  lne  MCF  approach  in  reducing  the  number 
(of  different  kinds)  of  things  to  support  is  on  track  as  is  having  a 
small  number  of  multiple  suppliers. 

Rear  Admiral  Meyer 

The  military  profession  is  war.  it  is  not  software,  hardware  or 
business.  War  is  our  number  one  requirement.  Groups  and  interests  in 
Washington  fend  to  drift  off  that  subject,  (his  presentation  will  be 
a  series  of  returns  to  this  criterion  to  compare  both  contributions 
and  readiness  for  war  with  it.  An  attempt  will  be  made  from  my 
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perspective  to  state  what  the  problem  is  or  should  be  and  to  discover 
whether  or  not  Ada,  TADSTAND,  or  5000.2  are  goinq  to  help  solve  it. 
What  mechanisms  are  going  to  be  invented  by  people  (in  this  community) 
who  work  on  the  solution  to  effective  war? 

A  recent  GAO  report  stated  it  could  not  cite  a  single  Joint 
program  that  had  been  effective  in  spite  of  thirty  years  of  trying. 
Their  conclusion  was:  It  ought  to  work  and  therefore  we  ought  to  work 
harder  on  it. 

for  my  remaining  time,  I  am  going  to  work  on  the  Battle  Group 
within  the  Navy  and  try  to  influence  the  design  of  the  Battle  Group  as 
the  fundamental  fighting  molecule  of  the  Navy.  Battle  forces  are  what 
we  fight  with. 

We  are  starting  with  a  cite  at  Wallops  Island,  Virginia  and  over 
the  next  B  to  10  years  significant  and  fundamental  changes  will  be 
made.  Work  is  commencing  on  installation  at  the  (bvstems)  Engineering 
Center  (SEC).  There,  the  basic  elements  of  a  Battle  Group  will  be 
designed  and  installed.  From  that,  effort  will  be  organized  to 
"system  engineer"  the  fighting  molecule  of  the  Navy.  Will  it  work?  I 
don't  know.  It  will  cost  money  and  it  is  necessary  in  that  it  is  the 
only  direction  1  have  found  that  is  compatible  and  harmonious  with  the 
social,  economic  and  logical  conditions  we  are  dealing  with  in  the 
Navy  today. 

Passing  over  detailed  discussion  of  instrumentation,  the  Battle 
Group  in  SEC,  the  engineering  and  the  superiority  of  operations  of  the 
men  in  the  Battle  Group  will  be  the  edge  in  winning  the  battle. 
Functionally,  it  can  be  broken  down  to  detection,  control  and 
engagement  as  in  the  AEGIS  program,  it  has  to  be  put  together 
structurally  and  to  function  operationally.  The  AEGIS  fleet  is  being 
put  together  that  way  but  there  are  some  problems  and  flaws  associated 
with  it.  Through  an  extraordinary  partnership,  we  have  proven  in  the 
United  States  that  we  do  know  how  to  put  together  large  real-time 
tactical  programs  that  deal  in  the  non-linear  aspects  of  battle  -  to 
the  tune  of  millions  of  words.  I here  are  35  or  4U  bays  of  computation 
right  in  the  center  of  riCONDEPOGA.  I  he  operational  program  alone  is 
of  the  order  of  a  million  words  and  many  million  of  woros  go  to 
sustain  it  and  support  the  different  elements  in  it.  The  operability 
has  been  proven  because,  on  her  maiden  voyage,  ilCONDtPOUA  sailed  into 
harm. 


The  Navy  will  build  25  such  cruisers  but  the  question  arises  "How 
can  the  Navy  keep  up  (programming  for  them)  and  keep  (the  software) 
together?"  The  answer  today  is  a  brute  force  approach  and  we  are 
putting  more  people  to  sustain  and  maintain  software  than  it  took  to 
develop  it.  It  is  expensive  and  if  (these  programs)  are  added  up  for 
the  battle  forces  of  the  Navy  today  there  would  be  on  the  order  of  a 
billion  words  (of  program)  to  be  maintained  over  the  next  decade  or 
so.  There  are  not  enougn  people  available  to  use  that  approach  and  to 
try  it  would  be  working  on  the  wrong  problem. 

The  Navy  seems  to  have  "worn  itself  out"  on  standardization  and 
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particularly  in  the  hardware  dimension  -  the  computers.  That  time  is 
past  and  (the  Navy)  needs  to  "wear  itselt  out"  on  computer  programs. 
The  computers  got  where  they  are  through  the  application  of  millions 
of  dollars  of  technology,  to  the  point  today  where  the  availability  ot 
computers  is  so  high  we  don't  attempt  to  measure  it.  Yet,  it  is  a 
major  breakthrough  if  the  program  in  a  ship  like  1IC0NDER0GA  does  not 
have  to  be  reloaded  in  a  period  of  twenty  four  hours.  The  computers 
run  for  thousands  and  thousands  of  hours.  I  he  Navy  needs  to  change 
direction  (in  software  development  and  maintenance)  and  it  appears 
research,  engineering  and  application  is  not  being  done  in  software 
and  programs  to  provide  techniques  in  software  analogous  to  what  was 
done  in  hardware.  It  does  not  appear  the  Navy  will  get  them  out  of 
efforts  underway  today.  That  is  where  the  basic  problem  is  and  where 
we  have  to  find  a  wav  to  solve  it.  We  cannot  sustain  the  sortware 
because  of  cost  even  it  we  can  buy  it.  Maintenance  is  goinq  to  kill 
us  (unless  we  do  something  about  it). 

In  looking  at  a  possible  solution,  the  "stretch  sock  svndrome"  - 
it  fits  everybody  and  nobody  -  snould  be  avoided  in  considering 
standardization  of  computer  programs.  I  he  (growth)  of  effective 
electrical  power  in  this  country  was  attained,  in  my  judgment,  through 
the  Underwriters  Laboratory  and  its  system.  A  major  thrust  of  the 
professional  societies  over  the  last  50  or  75  years  has  been  the 
promotion  of  standards  and  specifications  for  effective  use  of 
electrical  products.  None  appear  to  have  been  an  instrument  of 
government,  but  were  a  product  of  the  profession.  Underwriters 
Laboratory  methods  allow  much  variability  in  characteristics  of 
electrical  equipment  so  long  as  certain  protocols  are  not  violated. 

The  protocols  are  relatively  simple  and  very  permissive,  and 
protection  devices  are  built  into  the  system. 

Ihis  (property)  is  missing  from  tactical  warefare  computer 
programs.  We  are  not  qetting  there  from  here  and  it  does  not  appear 
Ada,  HOLs  or  more  0OU  instructions  will  get  us  there.  It  looks  as  if 
industry  will  have  to  get  us  there  and  the  question  is:  What  will  get 
industry  to  get  us  there/" 

There  has  to  be  a  partnership  but  there  is  question  that  there 
can  be  a  partnership  pursuing  the  policies  we  heard  stated  this 
morning.  DOU  and  Congressional  officials  have  discussed  partnership 
between  Congress,  Industry  and  DUD.  Weal  progress  on  it  is  not 
apparent.  The  fundamental  motivation  of  partnership  is  ability  of 
industry  to  continue  its  own  development.  There  does  not  appear  to  be 
a  scheme  to  accomplish  the  partnership. 

Referring  to  the  objectives  of  this  session,  emphasis  was  on 
discussion  of  known  issues  and  creation  of  a  partnership  so  as  to  have 
a  viable  (workable  and  likely  to  survive)  computer  and  software 
operation.  The  known  issues  are:  The  Navy  has  a  billion  words  of 
program  and  a  monstrosity  of  a  maintenance  problem  over  the  next  two 
decades.  The  second  issue  is  forming  an  effective  partnership  and 
discovering  how,  truly,  such  a  partnership  will  come  about.  The  third 
is  survivability,  not  in  the  direct  combat  sense,  but  survival  related 
to  maintenance  and  productivity  (of  software).  We  have  to  avoid 


-Z8- 


start-overs  and  endless  searches  when  programs  have  to  be  changed. 
Otherwise  we  will  have  obsolescent  tactical  programs.  We  must  pursue 
a  partnership  which  can  take  root  and  grow  over  the  next  decade.  The 
problem  is  a  system-engineered  battle  force.  Nothing  less  will  win. 
One  mechanism  for  creating  that  partnership  is  at  the  SEC  at  Wallops 
Island,  in  the  next  year  or  two,  and  industry  is  welcome  to  Join  up 
and  participate.  Finally,  not  estimating  but  controlling  software 
costs  is  the  only  way  we  will  get  (Battle  Group)  system  engineering. 

Brigadier  General  Hyde 

It  is  encouraging  that  Space  Command  was  selected  to  represent 
the  Air  Force  and  provide  an  Air  Force  perspective  on  problems  of  the 
services  in  the  future  in  the  business  of  hardware  and  software. 

Space  is  where  a  great  piece  of  our  future  lies.  The  Air  Force  -  all 
the  services  -  have  a  heavy  dependence  on  space.  Over  / 0%  of  our  long 
haul  communications  are  handled  by  satellites.  Satellite  systems  are 
a  key  part  of  our  warning  capability.  Our  military  weather  satellites 
provide  key  meteorological  data  to  all  the  services.  The  Global 
Positioning  System  will  let  us  navigate  world  wide  with  unprecedented 
accuracy.  It  will  ultimately  have  IB  satellites  in  orbit  and  provide 
positional  accuracy  to  10-15  meters.  There  is  more  to  come  in  space. 

This  discussion  will  look  into  the  future  and  future  key 
requirements  for  military  computer  systems.  It  with  our  missions 
today  and  the  challenges  we  have  right  now.  lhe  mission  are:  -  To 
warn  the  NCA,  the  JCS,  and  key  commands  around  the  world  of  foreign 
ICBM  and  SL6M  launches,  and  to  assess  each  and  all  as  possible  attacks 
on  North  America  (Air  Force  component  of  NORAU).  -  Space  defense, 
which  involves  surveillance,  protection  and  negation. 

Space  Command  and  Its  predecessors  have  been  doing  space 
surveillance  for  over  20  years.  Its  original  charter  was  space 
surveillance  -  detect,  track  and  catalog  all  man-maoe  objects  in 
space.  It  is  the  one  and  only  agency  that  provides  a  space  catalog 
for  the  entire  free  world  -  what  is  up  there,  who  owns  it,  how  it  got 
there  and  where  it  is  going.  Presently,  there  are  about  5100  objects 
in  space  and  about  2U,000  observations  a  day  are  required  from  sensors 
all  over  the  world  to  maintain  that  catalog.  Protection  involves 
warning  the  owners  of  those  objects  in  space  when  they  might  be 
getting  too  close  to  one  another  or  when  a  new  launch,  friendly  or 
foreign  might  come  too  close.  In  addition  to  protecting  against 
hostile  threats,  Space  Command  provides  collision  avoidance  prior  to 
launch  of  space  missions  by  comparing  tne  programmed  flight  path 
against  the  space  catalog,  it  is  very  important  for  missions  of  the 
Space  Shuttle  for  example.  Negation  (derives)  from  both  national  and 
DOD  space  policies  which  direct,  within  such  limits  as  might  be 
imposed  by  international  law,  the  continued  development  of  an 
operational  anti-satel loite  capability  to  deter  threats  to  friendly 
space  systems  and  to  preserve  our  right  of  self  defense. 

These  missions  are  carried  out  by  means  of  Satellite  Early 
Warning  Systems  (SEWS),  a  system  of  sensor  satellites  and  Ground  Based 
Sensors  -  radar,  optical,  infrared  and  other  -  the  outputs  of  which 
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are  processed  and  fed  over  an  extensive  Communications  net  to  the 
Cheyenne  Mountain  complex  in  Colorado  Springs.  There  these  data  are 
screened,  collated,  checked,  verified  and  processed  on  over  80 
computers  for  presentation  in  various  operations  centers  such  as 
NORAD/SPACE  COMMAND  Command  Post  or  the  Space  Defense  Operations 
Center.  That  is  a  quick  tour  through  a  very  complicated  system  that 
takes  over  9000  people,  plus  untold  others  associated  with  leased 
support  systems,  to  operate  and  maintain.  That  sets  the  stage  for  a 
brief  description  of  some  key  problems  ana  challenges  Space  Command 
faces  today  -  integrity,  time  urgency,  surviveabi 1 ity  and  capability. 

Because  an  inaccurate  or  ambigous  assessment  coming  from  the 
Command  Post  could,  at  the  worst,  set  U.S.  military  forces  in  motion 
or,  at  the  very  least,  cause  an  unnecessary  preparatory  posturing  of 
forces  that  could  be  alarming  to  friends  and  enemies  alike,  the  integrity 
of  the  total  systems  -  sensors,  communications,  computers  (both 
hardware  and  software),  procedures,  and  people  must  be  absolute.  It 
simply  may  not  fail*  kiccup,  be  inaccurate  or  be  ambiguous.  Morever, 
tne  system  must  be  extremely  fast  because  lLBMs  from  the  Soviet  Union 
are  only  30  minutes  away  and  SLBMs,  which  are  detected  and  tracked  by 
the  phased  array  (PAVE  PAWS)  radars  on  the  East  and  West  Coasts  are  as 
little  as  13  minutes  away.  Survivability  is  a  challenge,  too,  because 
even  though  the  Space  Command  Post  in  Cheyenne  Mountain  is  the 
hardest/most  survivable  Command  Post  in  the  Western  World,  some 
sensors  like  PAVE  PAWS  are  obviously  pretty  vulnerable.  Today  we  use 
a  big  phased  array  radar  at  Concrete,  N.D.  to  help  track  and  identify 
ICBMs  and  objects  in  space  and  it  does  that  (function)  extremely  well. 

But  it,  and  it  along,  is  the  only  remnant  of  the  anti-ballistic  missle 
capability  we  didn't  build.  We  have  no  capability  either  to  negate 
other  threatening  spacecraft.  That  is  a  challenge  as  well. 

Space  Command  is  going  operational  with  new  systems  and 
capabilities  in  and  for  space.  Under  development  and  beginning  to 
test  is  our  anti  sate  I  I ite  system  consisting  of  a  miniature  vehicle 
which  is  launched  from  F— 1 5  aircraft  stationed  at  Langley  and  McChord 
Air  Force  Bases.  In  operation.  Space  Command  would  inform  NCA  of  a 
threatening  satellite.  If  they  make  a  decision  to  intercept,  the 
orbital  parameters  would  be  computed  in  the  Space  Oefense  Operations 
Center  in  the  space  catalog  and  an  engagement  profile  as  well.  ASA1 
Mission  Control  Center  in  Cheyenne  Mountain  would  pass  intercept  data 
to  communications  processors  at  the  ASAT  F-15  Air  Bases.  A  profile 
tape  would  be  produced  and  inserted  in  the  F-15  along  with  the 
super-cooled  missle  that  is  going  to  do  the  job.  F-15  would  take  off 
and  follow  the  profile  to  the  launch  box.  At  the  programmed  time  and 
altitude  in  the  launch  box,  the  vehicle  is  launched  and  makes  the 
interception. 

Preparation  is  underway  to  replace  the  major  computer  systems  in 
Cheyenne  Mountain,  using  a  new  architecture  in  which  the  processing 
for  each  mission  area  is  done  in  a  distinct  computer  set.  It  is  not 
done  that  way  today.  Mission  areas  are  combined  in  various  ways  and 
carried  out  in  common  computers  and  we  find  that  is  not  a  good  way  to 
do  it.  Computer  sets  in  this  (new)  architecture  are  connected  to  the 
common  data  input  circuits  and  are  connected  to  common  display  by  some 
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kind  of  local  area  network  or  data  bus.  With  this  design  we  can 
modify  the  processing  for  any  one  mission  area  without  risk  of 
disturbing  the  others.  That  is  very  important  because  without  that 
capability  each  time  some  calculation  or  parameter  has  to  be  changed 
in  one  mission  area,  and  mission  areas  are  interlaced,  lines  and  lines 
of  code  have  to  be  examined  for  every  mission  area  there  is.  In 
addition,  with  this  kind  of  modular  architecture  processors  can  be 
added  for  new  mission  areas  as  they  might  be  assigned. 

Consolidated  Space  Operations  Center  (CSOC)  is  being  built  nine 
miles  east  of  Colorado  Springs.  One  side  of  the  CSOC  will  be  a 
Shuttle  and  Planning  Complex  which  will  functionally  replicate  the 
Johnson  Space  Center  in  Houston  and  provide  a  secured  facility  for 
carrying  out  Space  Command  mission  as  manager,  planner  and  operator 
for  all  military  space  shuttle  activities.  The  other  side  of  CSOC 
will  be  a  satellite  operations  complex  which  will  be  a  duplicate  of 
the  Satellite  Control  Facility  now  at  Sunnyvale,  California  and  from 
which  Space  Command  will  exercise  management  and  control  of  the  major 
present  and  future  DOD  satellite  systems  SEWS... the  Defense 
Meterological  Satellite  System... the  new  NAVSTAR  Global  Positioning 
Satel 1 ites. . .the  Defense  Satellite  Communications  Systems  and  the  new 
MILSTAR  constellation  of  survivable  communications  satellites  all 
through  a  world  wide  network  of  ground  based  satellite  tracking 
stat ions. 

Put  all  together  and  It  comes  to  distributed  processing  on  a 
global  scale,  a  global  intertwined  system  of  surveillance  and  warning, 
navigation,  command,  control  and  communications,  satellites  and  ground 
nodes,  with  all  manner  of  vehicles,  manned  and  unmanned,  whose 
on-board  systems  communicate  in  real  time  with  ground  based  elements. 
It  includes  space  borne  data  capture  and  processing, 
satel I ite-to-satel I ite  communications,  downlink  and  uplink 
communications  from  fixed  and  mobile  ground  and  air  control  centers 
and  tracking  stations,  and  communications  to  and  from  these  centers  to 
fusion  centers  at  various  commands  around  the  world. 

Further  in  the  future  a  space  based  radar  and  defense  against 
ballistic  missiles  may  be  invisaged  with  possibly  a  laser  or 
laser- like  weapon  that  can  destroy  an  1C6M  or  SLBM  early  during  its 
boost  phase.  Future  requirements  in  computers  and  software  include 
micro-micro-miniaturization,  very  large  scale  and  very  high  speed 
integrated  circuits,  hlgher-than-high  order  software  languages  and  all 
the  other  technology  advances  industry  can  provide.  There  are  a  few 
requirements  driven  by  Space  Command  mission  and  architecture  that 
stand  out  sufficiently  to  be  addressed  individually. 

Global  architecture  and  space-wide  deployment  of  those  system 
elements  absolutely  demand  distributed  processing.  This  applies  to 
the  architecture  overall  and  to  all  nodes  in  the  architecture.  More 
autonomous  on-board  processing  at  point  of  contact  will  be  required  to 
strike  a  balance  between  distributed  processing  and  network 
communications. 

Because  the  time-lines  are  short  and  the  mission  is  critical. 
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systems  must  be  absolutely  accurate,  failsafe,  fault  tolerant  and  with 
comprehensive  built-in  self  diagnostic  features.  Because  they  are 
space  based  they  must  be  self  healing.  Reliability  and 
maintainability  are  absolutely  crucial. 

The  universal  military  requirement  -  survivability  -  including 
protection  against  physical  and  electromagnetic  threats  and 
multi-level  security  against  tampering  must  be  met  in  future  space 
systems.  The  use  of  mobility  for  survivability  of  systems,  such  as 
are  in  Cheyenne  Mountain,  will  tax  the  computer  builders  of  the 
future. 

In  answer  to  questions  and  responses  to  comments  the  followinq 
points  were  made: 

- The  Air  force  Advocate  for  Competition  is  not  one  man  but  the 

entire  Air  force  procurment  structure. 

— Expert  systems  are- threshold  state-of-the-art  and  as  a  facet 
of  Al  they  offer  the  nearest  term  pay  off.  It  appears  they  will 
be  manageable  for  insertion  into  tne  Army  system  area.  Docu¬ 
mentation,  specifications  and  testing  are  problems  associated 
with  it.  It  is  estimated  that  the  first  useable  systems  will 
appear  in  five  years  in  the  intelligence  area  in  limited  classes 
of  problems. 

- Information  and  computer  sciences  curricula  appear  to  lack  the 

hard  core  disciplines  characteristic  of  engineering  curricula  in 
the  past  but  there  are  trends  toward  improving  these  curricula. 

- In  dealing  with  the  data  rights  issue  Incident  to  purchases  of 

commercial  data  equipment,  the  Navy  looks  at  data  rights  to  de¬ 
cide  what  data  rights  it  needs  for  its  purposes.  In  competitive 
strategies  when  data  rights  are  not  needed  they  will  not  be  re¬ 
quired.  In  systems  acquisitions,  data  riqhts  needs  will  be 
identified  up  from  and  measures  will  be  taken  the  acquire  them 
before  development  starts.  Occasionally  the  Navy  as  determined 
that  acquisition  of  data  rights  was  not  worth  the  cost  and  effort 
in  the  interest  of  war  readiness. 
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Or.  Lieblein 


This  session  will  cover  emerging  and  emerged  technologies. 
Technology  in  a  military  computer  context  is  a  mixed  bag.  To  some  it 
is  a  monster  -  how  to  deal  with  technology  in  the  context  of 
competition  and  standardization.  To  others  it  is  an  unstoppable  train. 
The  perspectives  presented  will  be  from  those  who  both  deal  with 
technology  and  work  every  day  at  it  -  in  important  technology  programs 
both  government  and  industry  sponsored. 

Attention  will  be  focused  on  where  the  technologies  discussed  are 
heading  and  where  we  will  be  in  5,  10  or  20  years.  Topics  are  VLSI, 
VHSiC,  the  Software  Factory  concept,  computer  architecture,  AI, 
strategic  computing  and  super  computing.  Problems  to  be  dealt  with  and 
near  term  opportunities  will  be  pointed  out. 

Dr.  Patterson 

This  discussion  will  point  to  silicon  technology  and  not  initially 
to  gallium  arsenide  or  J-J  devices  which  could  conceivably  play  a  role 
in  computer  technology  in  the  1990s.  it  is  based  largely  on  the  great 
effort  being  put  into  silicon  technology  and  the  inertia  inherent  in 
such  a  large  and  dynamic  industry. 

The  VHSIC  effort  was  started  in  the  late  70 's  to  reverse  the 
erosion  of  (U.S.)  technology  lead  over  some  adversary  countries.  We 
decided  DOD  was  not  doing  a  good  enough  job  to  get  1C  technology 
available  in  commercial  industry  into  its  systems.  This  was  the  prime 
driving  force  for  the  VHSIC  program.  OSD/DOD  wanted  to  address  the 
needs  of  the  signal  processing  capability  for  military  systems  and 
direct  its  efforts  totally  at  reducing  this  technology  insertion  gap 
and  getting  microelectronics  into  the  military  systems.  In  the  1960's 
DOD  had  advanced  microelectronics  in  its  systems  before  commerical 
(industry)  did.  In  the  1970's  commercial  industry  had  developed  LSI 
and  000  said  let  us  see  what  we  can  do  to  get  it  into  military  systems. 
That  added  another  five  years  to  make  these  devices  compatible  with 
military  requirements.  With  VHSIC  DOD/OSD  anticipated  where  industry 
would  be  in  the  mid  80 's  and  engaged  companies  to  see  how  this 
technology,  as  it  emerged,  could  be  applied  to  military  requirements. 

Inherent  with  the  complexity  of  VHSIC  chips  is  the  added 
reliability  which  has  always  been  a  problem  in  military  systems,  in 
reducing  part  counts  VHSIC  could  reduce  life  cycle  costs.  VHSIC  thinks 
a  hundred  fold  increase  in  reliability  will  come  about.  VHSIC  Phase  I 
development  stressed  bui It- in-test  and  should  improve  operational 
maintenance.  New  designs  for  fault  tolerance  have  been  examined. 
Military  systems  have  radiation  environment  requirements  that 
commercial  Industry  does  not  have. 

In  the  80 's  time  frame,  commerical  Industry  did  not  have  the 
throughgut  thajj  military  systems  needed  from  its  integrated  circuits. 
Then  10°  to  )0y  operations  per  second  were  quoted  for  military 
requirements.  These  levels  are  being  reached  with  some  Phase  I 
technologies.  Later,  submicron  developments  will  be  discussed  for 
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systems  that  need  even  higher  throughputs. 

In  Phase  1  VHSIC  wanted  industry  to  address  I  1/4  micron  feature 
size  suitable  for  subsystem  brassboards  for  military  applications. 

Also,  there  was  a  smaller  effort  on  device  problems  to  get  devices  down 
to  1/2  micron  feature  size. 

In  Phase  II  pilot  production  for  1/2  micron  chip  sizes  would  be 
started  and  I  1/4  micron  chips  would  start  to  be  put  in  military 
systems.  A  lot  of  perpheral  and  auxiliary  studies  needed  to  be  done 
and  nearly  $50  million  was  spent  on  Phase  II  programs  to  address 
problems  arising  out  of  this  technology. 

In  the  early  80 's  the  functional  throughput  rate  defined  as  a 
function  of  gate  density  (ga^s  per  square  centimeter)  and  the  clock 
speed  in  Hertz  was  around  10 1  and  typical  of  better  commerical  chips 
today.  VHSIC  1  addressed  funct i ona 1 ( throughput  of  5  x  10  .  VHSIC  II 

will  address  a  figure  of  merit  of  10  to  be  attained  in  the  next  few 
years.  Radiation  tolerance  and  easy  Insertion  were  also  stressed  for 
military  systems. 

A  variety  of  vendors  and  four  different  technologies  were  used  to 
address  these  problems.  Six  contracts  provided  a  variety  of 
architectural  approaches  and  with  brassboards  assured  applicability  to 
military  systems.  Among  the  packaging  problems  were  extremely  high  pin 
count,  chip  sizes  approaching  300  mils  on  a  side  and  power  dissipation 
of  1  to  3  watts.  Package  types  are  being  examined  including  pin-grid 
and  package  attachment  to  the  board. 

In  1984  the  end  of  Phase  I  is  upon  us.  There  are  no  impediments 
to  successful  fabrication  of  1  1/4  micron  chips.  DOO  accepts  and  wants 
VHSIC  for  military  systems  and  an  equal  number  of  pilot  lines  have  been 
company  funded.  This  has  resulted  in  government  and  industry 
proceeding  together  with  commerical  benefits  in  competitive  stature  and 
near  completion  of  six  fully  functional  chips  and  64k  RAM  types. 
Comparatively,  VHSIC  stresses  high  throughput  and  reliability  while 
commercial  industry  tends  toward  higher  gate  density  to  get  lower  cost. 

Looking  at  VHSIC  Phase  11  and  some  of  the  goals  of  the  sub-micron 
technology  effort,  chips  are  being  put  into  a  funded  fifteen  systems 
for  insertion  of  VHSIC  technology  into  military  systems.  Contracts  for 
improvement  of  yield  on  Phase  I  pilot  lines  have  been  announced  in 
order  to  bring  cost  down  to  a  reasonable  level  -  anticipated  to  be  $500 
per  chip  in  the  1986-88  time  frame.  There  is  also  a  manufacturing 
technology  program  underway.  The  Integrated  Design  Automation  System 
(IDAS)  is  aimed  at  a  very  big  military  problem  and  somewhat  less 
commercial  problem  -  improve  the  design  time  in  getting  to  the  chip 
mass  from  the  system  requirements. 

In  VHSIC  Phase  II  interconnect  and  packaging  technology  in  the 
1985  to  1988  time  frame  will  look  at  alternative  board  construction  to 
get  around  packaging  large  pin  counts  onto  the  package,  materials 
permitting  faster  speed  because  of  the  capability  of  the  board 
material,  tape  interconnects,  new  methods  of  package  attachment  to  the 
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boards,  new  carriers  for  higher  pin  count  and  putting  multi -chips  into 
the  packages  for  higher  packing  density. 

The  aim  of  IDAS  is  to  develop  software  to  facilitate  going  from 
the  operational  requirements  to  the  system  to  automate  as  many  of  the 
steps  as  possible,  and  to  get  down  to  the  final  pattern  generation  for 
defining  the  silicon  pattern  on  the  chips. 

A  sub-micron  capability  is  needed  because  speeds  we  are  getting 
today  are  not  sufficient  for  high  throughput  needed  in  some  key  areas. 

In  this  we  will  perhaps  be  leaving  optical  lithography  and  goinq  to 
E-beam  or  X-ray  lithography,  double  level  metallization  on  the  chip 
and  dry  etching. 

Submicron  devices  have  been  made  at  the  individual  transitor 
level,  modeling  is  improving  and  we  see  no  real  problems  in  being  able 
to  fabricate  half  micron  technology  in  the  late  1980's. 

Soon,  a  statement  of  work  for  the  sub-micron  process  development  of 
chip  needs  where  the  clock  speeds  are  going  up  to  I00MHZ  over  the  25  MHZ 
now  current  will  be  addressed.  Chips  of  gate  density,  in  the  logic 
area,  of  100,000  gates  per  chip  will  be  addressed,  in  the  memory  area 
we  anticipate  technology  affording  256K  static  random  access  memory. 

Pin  count  for  packages  will  go  up  to  300  again. 

There  is  a  commonality  with  commercial  industry  and  both  are 
approaching  state  of  the  art  at  about  the  same  frame  rate.  000 
money  is  getting  new  developments  put  into  military  rather  than 
commercial  systems. 

from  the  VHS1C  program,  we  expect  to  be  in  sub-micron  technology 
in  the  late  80' s.  We  anticipate  gate  delay  speeds  of  less  than  1  nano¬ 
second.  Chip  complexities  of  100,000  chips  per  device  wi|l  give 
throughput  rates  of  10  3  gate  hertz  per  centimeter  and  10  u  and  more 
operations  per  second  throughput. 
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Dr.  Mathis 


Ada*  PROGRAM 


TECHNOLOGY 

,  —STANDARD  LANGUAGE 

—  Ada*  PROGRAMMING  SUPPORT  ENVIRONMENTS 
-METHODOLOGIES 

EDUCATION  AND  TRAINING 

POLICY  AND  PUBLIC  INTERFACE 

APPLICATIONS 

GENERAL  MANAGEMENT 

^■^Ada^laaraglrtaradlfadamartiolihaUA.OowmmanHAdaJoi.a^ojramOfllca)"** 

In  the  1982  fiscal  Appropriations  Act  Congress  mandated  the 
acceleration  of  the  Ada  Program  and  that  Is  exactly  what  ObD/Ada  Pro¬ 
gram  Office  has  been  doing.  In  emerging  technologies  if  you  wait  ’’un¬ 
til  the  horse  has  left  the  gate",  you  "cannot  place  a  bet",  in  terms  of 
emerging  technology  Ada  is  an  existent  technology  -  there  are  validated 
compilers  and  so  on. 

lhis  slide  shows  the  role  of  Ada  and  includes  a  "waterfall" 
diagram  of  software  development,  a  small  role  in  coding  and  the  many 
other  activities  in  software  development  we  need  to  focus  on.  Ada  is  a 
way  of  focusing  on  mission  systems  requirements  and  other  large  areas 
that  have  to  be  addressed.  000  is  also  focusing  its  tremendous  power 
as  a  consumer  to  get  things  done  its  way.  Ada  is  really  changing  the 
way  software  is  developed,  purchased,  paid  for  and  maintained  over  the 
life  cycle.  That  is  why  chose  000  -  Industry  cooperation  is  needed. 


Mission 


In  a  changing  market  place  OSD/DOO  wants  to  make  sure  that  its 
friends,  our  ADA  users  -  people  who  have  gotten  on  the  Ada  bandwagon, 
turn  out  to  be  successful  in  the  overall  marketplace.  Because  it  is 
with  successful  companies  we  like  to  do  business. 

At  hi  LOOM  I  there  was  considerable  support  for  Ada  standardization 
and  for  software  standardization  to  drive  our  overall  mission  critical 
computer  programs.  At  MlLCOh  II  there  was  considerable  support  -  so 
much  so  that  it  was  not  really  discussed  as  a  controversial  item.  Ihe 
message  from  MlLCOh  111  might  be,  in  baseball  parlance,  if  vou  don't 
hear  it  the  third  time  it  is  three  strikes  and  you  are  out.  I  do  not 
think  there  is  any  other  software  or  software  engineering  game  in  town 
except  Ada.  Don't  get  the  impression  I  am  supposed  to  be  impartial.  I 
am  the  chief  Ada  pusher. 


STANDARD  ADA*  LANGUAGE 


o 

o 


ANS1/MIL-STD-1815A-1983 
Validated  Processors: 

New  York  University  -  Ada/ED 
ROLM/Data  General  -  ADE 
Western  Digital/Gensoft 
Telesoft.  Army  ALS.  Air  Force  AIE,  etc 


17  February  1983 

11  April  1983 
13  June  1983 
9  August  1983 


After  a  long  competitive  requirements  analyses  and  design 
competition,  Ada  was  finally  approved  as  an  American  National 
Standard  on  17  February  1983.  This  is  a  significant 

ACCOMPLISHMENT  FOR  THE  PROGRAM  IN  THAT  IT  INDICATES  BOTH  MILITARY 
AND  INDUSTRY  ACCEPTANCE  OF  THE  LANGUAGE  AS  A  STANDARD.  FOLLOWING 
THE  ACCEPTANCE  OF  THE  STANDARD,  THE  FIRST  PROCESSORS  FORMALLY 
VALIDATED  WERE  FROM  NEW  YORK  UnI VERS  I TY^  ROLM/DaTA  GENERAL  AND 

Western  Digital  (now  marketed  by  Gensoft).  In  the  next  twelve 

MONTHS,  WE  EXPECT  TO  SEE  COMPILERS  FROM  TELESOFT.  THE  Army's  Ada 

Language  System  (ALS),  the  Air  Force's  Ada  Integrated  Environment 

(AIE),  AND  PROBABLLY  OTHERS  COMING  FOR  VALIDATION.  ThE  PROCESS 
OF  VALIDATION  IS  A  VERY  RIGOROUS  TESTING  FOR  CONFORMANCE  TO  THE 

standard:  it  does  not  necessarily  indicate  the  suitability  of  a 

PARTICULAR  COMPILER  FOR  ANY  GIVEN  PROJECT. 

*  Ada  is  a  registered  trademark  of  the  U.S.  Government  (Ada  Joint 
Program  Office) 

As  to  the  status  of  Ada,  there  are  three  validated  compilers  -  New 
York  University,  Rolm  and  Data  General.  Western  Digital  validated 
their  compiler  in  August  and  immediately  sold  the  rights  to  a  new 
company  called  GENSOFT.  The  SOFTECH  AOS  being  written  for  the  Army 
will  be  coming  for  validation  in  the  early  summer  (I9B4).  The 

i N I ERMtTRI CS,  written  compiler  for  the  Air  Force  Ada  Integrated  Environment  (AIE) . 
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will  be  coming  for  coming  for  validation  in  late  fall  of  1984.  it  is 
expected  that  the  TELESOFT  compilers  written  for  their  own  purposes  and 
in  conjuction  with  IBM  on  the  SUBACS  project  will  be  coming  for 
validation  in  the  early  part  of  1984.  The  Danish  Datematric  Center, 
York  University,  ALS1S  from  Europe  will  all  be  submitting  their 
compilers  during  the  coming  year,  and  other  products  are  expected. 


Ada*  Use 

o  Defense  Authorization  Act,  1983 

'  .  .  .  Accelerate  .  .  .  Ada  .  .  .' 
o  DeLauer  Memo  10  June  1983 
DoDD  3*105. xx  (DoDI  5000.31) 

Ada  to  be  used  on  new  programs  in  1989 
o  Services  aggressively  planning  for  Ada 

In  the  Defense  Authorization  Act  for  1983,  Congress  said 
that,  'The  Department  of  Defense  should  accelerate  implementation 
of  the  Ada  high  order  language  and  constrain  to  the  maximum 

EXTENT  FEASIBLE  SERVICE  VARIATIONS  ON  Ada  TO  ENSURE  THE  UTMOST 
COMMONALITY  OF  SYSTEMS  SUPPORT  SOFTWARE*.  In  KEEPING  WITH  THIS 

direction.  Under  Secretary  of  Defense  for  Research  and 
Engineering.  Richard  D.  DeLauer  issued  a  Memo  dated  June  10,  1983 
circulating  what  used  to  be  called  DoD  Instruction  5000.31  for 

FINAL  COORDINATION.  DUE  TO  RENUMBERING  THIS  WILL  BE  CALLED  DoD 

Directive  3905. XX.  In  that  memo,  DeLauer  said  that,  'Ada 
(ANSI/MIL-STD-1815A-1983)  is  approved  for  use  consistent  with  the 

INTRODUCTION  PLANS  OF  THE  INDIVIDUAL  COMPONENTS  AND  THE 


'  Ada  is  a  registered  trademark  of  the  U.S.  Government  (Ada 
Joint  Program  Office). 

validation  requirements  of  the  Ada  Joint  Program  Office.  The  Ada 

PROGRAMMING  LANGUAGE  SHALL  BECOME  THE  SINGLE,  COMMON  COMPUTER 
PROGRAMMING  LANGUAGE  FOR  DEFENSE  MISSION-CRITICAL  APPLICATIONS. 

Effective  1  January  1989  for  programs  entering  Advanced 
Development  and  1  July  1989  for  programs  entering  Full-Scale 
Engineering  Development,  Ada  shall  be  the  programming  language... 
Other  programs  are  encouraged  to  use  Ada  as  soon  as  and  whenever 

POSSIBLE.' 

The  services  are  currently  revising  their  introduction  plans 

IN  CONFORMANCE  WITH  THIS  DIRECTIVE  FOR  ACCELERATION.  ALTHOUGH 
THE  DETAILS  ARE  STILL  BEING  WORKED,  IT  IS  CLEAR  THAT  EACH  OF  THE 
SERVICES  HAS  AN  AGGRESSIVE  PLAN  FOR  EARLY  USE  OF  Ada. 
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You  are  all  familiar  with  the  June  10  Dr.  Lauer  memo  mandating 


Ada. 


The  next  item  is  the  really  new  emerging  area  that  OSD/Ada  Program 
Office  would  like  everyone  to  become  familiar  with.  These  are  the  Ada 
Programming  Support  Environments  (APSEs). 


Ada*  Programming  Support  Environment 


o  STONEMAN 

o  Rehost.  Retarget,  Retool 

o  KIT.  K1TIA 

o  Common  APSE  Interface  Set  (CA1S) 
o  Early  release  of  ALS 
o  Environment  Evaluation  ano  Validation 

Important  as  the  Ada  language  is.  even  greater  benefits  will 

BE  DERIVED  FROM  THE  USE  OF  COMMON  Ada  PROGRAMMING  SUPPORT 

Environments  (APSE).  This  idea  was  recognized  early  in  the  Ada 
PROGRAM  AND  THE  STONEMAN  DOCUMENT  DEFINEO  A  MODEL  FOR  THE 

construction  of  an  APSE.  This  was  the  basis  for  the  design  of 
both  the  Army's  Ada  Language  System  (ALS)  and  the  Air  Force's  Ada 
Integrated  Environment  (A1E).  Other  systems  are  also  followng 
this  model. 

This  lead  to  our  plan  tD  develop  a  programming  support 

ENVIRONEMNT  WHICH  WAS  REHOSTABLE,  RETARGETABLE.  AND  RETOOLABLET 
MEANING  THAT  WE  COULD  RUN  THE  SAME  PROGRAMMING  SUPPORT 
ENVIRONMENT  ON  A  NUMBER  OF  DIFFERENT  HOSTS.  TARGET  IT  FOR  A  WIDE 

*  Ada  IS  A  REGISTERED  TRADEMARK  OF  THE  U.S.  GOVERNMENT  (Ada 

Joint  Program  Office). 


revised 
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VARIETY  OF  MANY  COMPUTERS  AND  ENVIRONMENTAL  CHARACTERISTICS  AND 
ALSO  PROVIDE  A  HARKET  PLACE  FOR  ADVANCED  SOFTWARE  DEVELOPMENT 
TOOLS. 

The  KAPSE  Interface  Teah  (KIT)  and  the  KAPSE  Interface  Team 
Industry/Acadamia  (KITIA)  were  set  up  to  study  the  problems  of 

REHOSTING.  RETARGETING,  AND  RETOOLING  PARTICULARLY  AS  THEY  APPLY 
TO  THE  ALS  AND  AIE.  ThEIR  WORK  IN  THAT  AREA  HAS  LEAD  TO  A 
DOCUMENT  NOW  REFERRED  TO  AS  A  COHMON  APSE  INTERFACE  SET  (CAIS). 

This  was  released  for  public  discussion  in  September  1983  and  may 

EVENTUALLY  BECOME  A  STANDARD  FOR  SOFTWARE  DEVELOPMENT  SYSTEMS. 

In  November  1983,  the  ALS  was  released  for  potential 

REHOSTERS  AND  RETARGETERS  TO  BEGIN  LEARNING  ABOUT  THE  STRUCTURE 
OF  THE  ALS  AND  BEGIN  WORKING  WITH  IT. 

With  a  number  of  environments  potentially  available  for  use 

ON  A  PROJECT,  IT  BECOMES  IMPORTANT  FOR  US  TO  KNOW  THE 
CHARACTERISTICS  OF  THEM  AND  THEIR  APPLICABILITY  IN  THE  SITUATION 
UNDER  CONSIDERATION.  FOR  THAT  REASON.  THE  AJPO  HAS  SET  UP 
ANOTHER  TASK  CALLED  ENVIRONMENT  EVALUATION  AND  VALIDATION,  WHICH 
WILL  HELP  DEVELOP  THE  APPROPRIATE  EVALUATION  CRITERIA  FOR 
DECIDING  BETWEEN  THE  VARIOUS  TOOLS  AND  ALSO  THOSE  ASPECTS  OF 
ENVIRONMENTS  INTO  WHICH  WE  CAN  EXTEND  THE  COMPILER  VALIDATION 
IDEAS. 


Through  the  KIT  or  KITIA  effort,  Ada  oroqram  office  has  now  come  out 
with  a  common  APSE  interface  set.  This  is  a  model  for  standard 
interfaces  between  Ada  development  tools  and  the  underlying  operating 
system.  In  many  ways,  it  is  UNIX  grown  up  and  re-cast  in  Ada  terms. 
People  familiar  with  UNIX  concept  will  find  transition  to  CAIS  straight 
forward.  OSD/Ada  Program  Office  is  beginning  to  sponsor  some  projects 
that  will  be  directly  demonstrating  how  UNIX-related  software 
tecnniques  can  be  directly  transitioned  to  CAIS.  With  the  tools  we 
have  with  Ada,  OSU/Ada  Project  Office  wants  an  expanded  framework  over 
UNIX  in  such  areas  as,  for  example,  a  better  file  structure. 


CAIS  SCHEDULE 

16  NOVEMBER  1983  (REVISED) 


•  DRAFT  VERSION  1.0 

•  PUBLIC  REVIEW 

•  DRAFT  VERSION  1.1 

•  PU8UC  COMMENTS 

•  SERVICE  TECHNICAL  COMMENTS 

•  DRAFT  VERSION  1JB 

•  DRAFT  VERSION  1.3 

•  MIL-STD  VERSION  1 

•  INITIATE  MIL-STD  VERSION  2 

•  DRAFT  VERSION  2  (SEE  NOTE) 

•  MIL-STD  VERSION  2 


-  26  AUGUST  1983 

-  14-15  SEPTEMBER  1983 
••  30  SEPTEMBER  1983 

-  1  NOVEMBER  1983 

-  IS  DECEMBER  1M3 

-  APRIL  1944 

-  NOVEMBER  1984 

-  JANUARY  19*5 

-  JANUARY  IMS 

-  JANUARY  1986 

-  JANUARY  1987 


NOTE:  CONFIGURATION  CONTROL  OF  ALS,  AIE  AND  CAIS  BY  SOME  JOINT  SERVICE 
CONFIGURATION  CONTROL  BOARD 
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This  is  the  CAIS  schedule.  It  is  out  for  technical  comment. 
OSD/Ada  Project  Office  expects  to  issue  a  revised  draft  in  April  and 
November  1984  with  the  goal  of  having  a  MILSTD  in  January  1985.  The 
MILSTD  (CAIS)  will  then  be  revised  and  put  under  configuration  control 
by  the  Configuration  Control  Board  that  manages  ALS  and  A1E,  and 
probably  the  Navy  ALSN.  This  will  provide  a  link  between  people 
working  on  standards  and  interfaces  and  those  who  have  existing  systems 
to  be  maintained.  A  revised  MILSTD  is  targeted  for  January  1987  at 
which  time  A1E,  ALS,  ALSN  and  the  revised  CAIS  standard  will  all 
conform  to  one  another.  The  CAIS  will  be  the  standard  for  any  new  Ada 
support-related  tools. 

OSD/Ada  Program  Office  is  moving  into  the  methodologies  area  and 
expanding  the  role  of  Ada  to  cover  requirements  and  design  languages 
and  expert  development  systems.  Work  is  starting  on  the  programming 
support  environment  for  the  next  generation  (computers),  for  example, 
the  library  system  of  the  I9b0's  was  a  sequential  listing  of  programs 
on  a  tape.  It  is  totally  unsatisfactory  for  reuse  of  complicated 
software  modules.  Ada  program  is  headed  for  resueability  of  software 
and  run-time  standards  are  projected  for  tne  tarqet  environment.  These 
will  provide  the  same  kind  of  services  for  executing  programs  that  CAIS 
provides  for  development  systems.  The  first  draft  of  a 
Transportability  Handbook  is  expected  by  the  end  of  1984.  An  Evaluation 
and  Validation  of  Programming  Environments  Working  Group  is  holding  a 
workshop  April  2-6,  1984.  it  is  an  extension  of  Compiler  Validation 
efforts,  it  earlier  KITIA  efforts  and  was  announced  in  CBD  about  2 
weeks  ago. 
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OSO/Ada  Program  Office  now  nas  permission  to  work  on  International 
Standard  Organization  (ISO)  standards.  ISO  has  a  technical  committee 
on  computer  standards,  sub-committee  5  on  programming  languages  and 
working  group  1 4  on  Ada  standards.  ISO  includes  Soviet  Union  and 
Peop I  e '  s  Repub  lie  of  China. 

In  conclusion,  Ada  and  STARS  are  the  mainstream  of  software 
engineering,  it  Is  a  big  advantage  of  Ada  to  the  DOD.  The  coiwnunity, 
as  in  the  Ada  program,  wanted  to  look  at  the  same  kinds  of  software 
engineering  problems  first.  Ability  to  work  in  Ada  will  be  requisite 
to  taking  advantage  of  work  to  be  done  in  industry  and  the  university 
in  expert  systems  and  future  computing  in  the  1990's. 

Supplementary  information  on  Ada  Proqram  is  provided  on  the 
following  five  slide  reproductions. 


CAIS  -  COMMON  APSE  INTERFACE  SET 


CHARACTERISTICS 

HAS  A  RELATIVELY  SIMPLE,  UNIFORM  UNDERLYING  MODEL 
DOES  NOT  UNDULY  INTERFERE  WITH  IMPLEMENTATION  STRATEGIES 
INTEGRATES  SMOOTHLY  WITH  THE  FEATURES  OF  ADA* 

PROVIDES  A  FLEXIBLE  FOUNDATION  FOR  CONFIGURATION  MANAGEMENT 
MERGES  MODERN  OPERATING  SYSTEM  AND  DATABASE 
MANAGEMENT  SYSTEM  IDEAS 


Add*  is  a  registered  tredemerk  of  the  U.S.  Government  (Ade  Joint  Program  Office) 
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KIT/KITIA 


>v 


KAPSE  INTERFACE  TEAM 

JANUARY  1982  MEMORANDUM  OF  AGREEMENT 
A  NAVY  LED  DOD  TEAM 

KAPSE  INTERFACE  TEAM  FROM  INDUSTRY  AND  ACADEMIA  (KITIA) 

CHARTERED  TO  FORMULATE  INTERFACE  STANDARDS 

—FACILITATE  MOVEMENTOFTOOLSAND  DATA  BETWEEN  APSES 
— AIE,  ALS  AND  ALL  OTHER  DOD  APSES  CAN  EVOLVE  TO 


Ada*  is  a  registered  trademark  of  the  U.S.  Government  (Ada  Joint  Program  Office) 


SATELLITE  FACILITIES 


INSTITUTE  FOR  DEFENSE  ANALYSES 
WPAFB  -  LCF 

(LANGUAGE  CONTROL  FACILITY) 
GSA/FCTC 

(FEDERAL  COMPLIER  TESTING  CENTER) 
GERMANY  MOD/IABG 
ENGLAND  NPL 
CEC  (“COMMON  MARKET') 


Ada*  is  a  registered  trademark  of  the  U.S.  Government  (Ada  Joint  Program  Office) 
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ADA  BOARD 


AJPO  DIRECTOR'S  ADVISORY  BOARD 

OFFICIAL  FEDERAL  ADVISORY  COMMITTEE 

STANDARDS  MAINTENANCE 
— MIL-STD 

—ANSI  PUBLIC  COMMITTEE 
—ISO  EXPERTS  GROUP 

PLANNING  MEETINGS 

—13  MAY  1983 
-4-5  AUGUST  1983 
—18  OCTOBER  1983 

TECHNICAL  SUPPORT 


Ada*  is  a  registered  trademark  of  the  U.S.  Government  (Ada  Joint  Program  Office)  « 


Ada®  JOINT  PROGRAM 
OFFICE  STAFF 


DR.  ROBERT  F.  MATHIS 
DIRECTOR 

MS  JUNE  LUDWIG 
MS  DORIS  REEVES 
SECRETARIES 


LT.  COL  RICHARD  STANLEY 
ARMY  DEPUTY  DIRECTOR 

LCDR  BRIAN  SCHAAR,  USN 
NAVY  DEPUTY  DIRECTOR 

LT.  COL  VANCE  A.  MALL  USAF 
AIR  FORCE  DEPUTY  DIRECTOR 


TO  CONTACT  THE  Ada0  JOINT  PROGRAM  OFFICE 


MAIL: 

Ada0  JOINT  PROGRAM  OFFICE 
RM.  3D139.  (400  A/N)  PENTAGON 
WASHINGTON,  D.C.  20301 
TELEPHONE:  (202)  694-0209 
AV  224-0209 


ARPANET: 


MATHIS 

@  ECLB 

MALL 

@  ECLB 

SCHAAR 

@  ECLB 

STANLEY 

@  ECLB 

Ada*  is  a  registered  trademark  of  the  U.S.  Government.  (Ada  Joint  Program  Office) 
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Dr.  Manley 


This  presentation  will  relate  to  STARS  program,  software 
engineering  and  software  factories  -  present  status  ana  future 
prospects.  STARS  is  aiming  to  solve  the  Navy  "billion  word"  plus  other 
services  software  maintenance  problems.  Software  maintenance  is  labor 
intensive  and  it  is  growing.  One  driver  was  the  projection  that  there 
would  not  be  enough  programmers  to  handle  future  problems.  So  one 
alternative  was  some  way  to  reduce  labor  intensiveness. 

STARS  aims  at  an  order  of  magnitude  improvement  over  a  seven  year 
Joint  program.  It  is  not  only  computer  system  practices  but  also 
business  practices,  the  acguisition  program,  data  rights  and 
competition.  It  is  not  just  technology  but  a  very  broad  program  of  the 
whole  spectrum  in  trying  to  improve  computer  technology. 

In  this  session  emphasis  is  on  methodologies,  tools  ana  integrated 
software  environments.  In  the  Ada  world  "environment"  is  ooing  outward 
from  the  compiler  to  minimum  Ada  support  environment,  to  a  larger 
environment.  Today,  it  starts  with  a  concept  of  software  that  goes 
into  a  system  -  really  it  starts  with  the  system  -  and  allocation  down 
to  software  tnrough  the  software  development  life  cycle,  back  to 
integration  into  a  system  and  the  whole  life  of  the  system  over  I CJ , 2U 
or  30  years.  Ihe  environment  of  a  30  or  40  year  span  is  another 
perspective.  "Life  cycle"  refers  to  the  entire  life  cycle,  not  just 
building  software . 

There  are  almost  as  many  definitions  of  "software  engineering"  as 
there  are  writers  and  experts  on  the  subject.  It  is  generally  conceded 
"software  engineering"  started  in  l^bB  in  a  NAiG  conference  and  was 
enunciated  by  fritz  Bauer,  it  is  a  young  term,  and  in  spite  of  not 
having  a  generally  accepted  definition  of  it,  the  overall  principles  of 
sofware  engineering  are  generally  accepted. 

Systems  in  this  context  are  becoming  so  large  and  complex  there  is 
great  difficulty  in  coping  with  them.  So  one  principle  is  to  simplify 
fhe  complexity.  Although  there  are  buzz  words  on  how  to  do  it, 
simplification  is  putting  structure  into  the  process,  the  code  and 
modularization.  Putting  discipline  not  onlv  into  the  process  of 
programming  but  also  into  its  management,  into  training  of  people,  into 
personnel  systems,  subsystems  and  interfaces  in  a  complete  life  cycle 
framework.  In  a  life  cycle  approach,  it  is  not  just  programmers  or 
other  separate  skills  involved.  It  is  also  managers,  users, 
maintainers,  developers  and  designers.  It  is  not  a  one-person  or  one- 
skill  operation.  It  is  a  lot  of  people  and  that  is  software 
engineering. 

Recently  the  need  and  advocacy  of  re-usable  parts  or  code  or 
standard  parts  because  the  wheel  keeps  being  re-invented  -  over  and 
over  again- in  modules  and  algorithms  in  different  systems. 

A  third  point  is  automation,  as  far  as  possible,  of  the  entire 
process  from  reguirement  specification  to  automatic  code.  in  the  MIS 
and  BIS  world  fourth  generation  languages,  wnich  are  rather  trivial 


-46- 


compared  to  military  systems,  the  user  can  be  led  through  to  generate  a 
COBOL  program  which  will  then  generate  a  report  rather  than  have  the  DP 
shop  do  it. 

If  the  word  "software"  is  removed  it  becomes  principles  of 
engineering  or  of  systems  engineering.  So  software  engineering  is 
things  that  have  been  done  all  along  in  other  fields. 

Software  engineering  is  being  practiced.  Leading  aerospace 
companies  and  most  space  andd  efense  contractors  are  using  these 
principles  in  one  form  or  another.  Also,  in  the  commercial  world 
there  are  mission  critical  systems  such  as  nuclear  power  plant 
control  systems  and  electrical  power  control,  CAT  scan  systems, 
eletronic  funds  transfer  systems.  Some  MIS  and  BIS  systems  in  commerce 
and  the  government  are  also  using  these  systems.  Engineers  who  are 
putting  microprocessors  into  fuel  injection  and  home  appliances  are 
treating  software  as  a  component  part  and  have  learned  to  program. 
Software  engineering  is  now  starting  even  in  that  small  shop 
wor I d . 

The  challenges  are  first,  how  to  automate  individual  methodologies 
and  to  integrate  steps  of  them.  Second  is  education  and  training  of 
people  in  these  principles.  This  comes  to  the  third  challenge  and 
biggest  point  -  cultural  change. 

All  the  leading  telecommunications  companies  are  writing  big 
public  switching  systems.  The  only  way  they  can  achieve  success  in 
writing  those  large,  complex  and  interactive  programs  is  to  use 
software  principles.  There  is  no  other  way. 

IEEE  is  now  advocating  standards  for  software  engineering.  ACM  is 
at  a  "software  engineering  notes"  level  and  is  plugging  software 
engineering  in  all  of  its  literature.  There  are  others.  Major 
universities  are  now  starting  to  shape  curricula  to  include  software 
engineering. 

One  thing  of  importance  is  the  SE1  of  the  DOO.  Similarities 
between  hardware  and  software  engineering  are  growing  but  some 
differences  remain.  The  art  and  craft  of  the  single  programmer  is 
getting  into  the  trade  process  -  skill  in  techniques  which  are 
repeatable.  Those  trades,  where  the  future  is  going,  can  be  integrated 
into  complete  factories. 

The  hardware  factory  has  the  line  that  produces  the  product  and 
support  functions.  The  line  is  all  steps  from  receipt  of  raw  materials 
to  exit  of  finished  goods.  Support  functions  include  planning 
manaugement  personnel,  training  and  industrial  engineering.  Quality 
control,  inventory  controls,  maintenance  of  plant  equipment  and  the 
controller.  All  are  involved  except  the  repeatable  manufacturing 
processes  in  software  engineering  and  that  too  may  exist  (in  some 
cases) . 

Software  engineering  is  new,  its  principles  are  acceptable  and 
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in  use  and  "factories"  will  be  the  next  step.  The  caveat  is  that 
sotware  technology  is  not  standing  still  and  state  of  the  art  is  always 
ahead  of  state  of  practice.  STARS  is  trying  to  make  all  of  that 
happen.  SE1  is  a  catalyst  that  can  accelerate  the  transition.  These 
together  with  Ada  can  make  it  all  happen.  The  principles  of  software 
engineering  are: 

. . .Structure 

...System  Perspective 

...Life  Cycle  Framework 

...Management  Discipline 

...Simplification  of  Complexity 

...Multi-discipline  learn  Approach 

...Reuseable  Standard  Parts 

...Automation-Requirement  Specification  to  Coding 
MR.  SQUIRtS 

The  Strategic  Computing  Program  is  focused  on  machine  intelligence 
technology,  not  supercomputing  technology  in  the  conventional  sense. 

From  the  beginning  OARPA  intended  to  stay  out  of  the  supercomputing  game 
in  the  conventional  sense. 

lhe  goals  start  with  development  of  a  broad  base  of  machine 
intelligence  technology  that  will  greatly  increase  national  security 
and  economic  strength.  These  new  technologies  will  be  tied  into 
demonstration  applications  in  such  a  way  that  results  will  rapidly  be 
made  avaiable  to  industry  for  other  spin-offs.  Many  of  the 
architectures  (the  program)  will  be  developing  will  have 
cost/performance  and  raw  performance  capabilities  well  beyond 
conventional  super-computing  architectures. 

The  underlying  technologies  which  make  this  program  possible  have 
emerged  over  the  last  five  years  or  so  and  by  combining  them  and 
jointly  leveraging  them  we  expect  to  get  this  new  generation  machine 
i nte 1 1 i gence  techno  I ogy . 

Expert  systems  is  the  most  useful  result  in  recent  times  from  the 
A I  program. 

There  is  a  clutch  of  other  kinds  of  artificial  intelligence 
approaches  which  has  to  do  with  recognizing  continuous  speech,  vision 
doing  real  time,  scene  analysis  and  related  areas. 

In  addition,  these  application  areas  represent  large  scale  system 
developments  and  OARPA  intends  to  develop  the  applications  in 
state-of-the-art  system  environments  as  they  become  available,  LISP 
environments  that  are  already  available,  and  developing  new  tools  to 
support  use  of  the  emerging  multiprocessor  technology. 

There  are  some  new  theoretical  insights  into  computer  science  that 
give  us  some  idea  how  use  can  be  made  of  large  numbers  of  processors. 
Architectures  that  have  on  the  order  of  hundred  or  thousands  of  micro 
processors.  Architectures  which  support  millions  of  small  grained 
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processors  such  as  one  bit  wide  processors.  And  the  corresponding 
software  to  effectively  use  them. 

The  three  main  functional  areas  in  computer  architecture  are 
signal  processing  (which  are  the  front  end  of  these  (expert)  systems), 
expert  systems  noted  above  and  multi-funct Ion  machines  which  are  large 
number  of  conventional  processors  assembled  in  novel  ways. 

Use  will  be  made  of  the  rapid  VLSI  fabrication  capabilities  which 
DARPA  developed  over  the  years  and  these  will  be  scaled  up  to  the  point 
of  rapid  turn  around  for  VLSI  parts,  boards  and  whole  systems.  Thus 
decisions  as  to  what  systems  to  build  will  be  deferred  as  long  as 
possible  and  then  "over  the  weekend"  deliver  the  product  loaded  with 
software.  This  is  an  integrated  rapid  systems  prototyping  approach  to 
these  systems.  In  the  early  years  development  will  be  done  the 
conventional  way.  By  the  second  phase  of  the  program  which  is  about  3 
years  out  in  a  1(J  year  program  there  will  be  this  rapid  systems 
prototyping  capability  and  a  new  experimental  base  to  work  in. 

Pushing  on  microelectronics  fabrication,  DARPA  will  be  glad  to  make 
use  of  VHSIC  foundaries  as  they  become  available.  In  the  architectures 
being  developed,  VHSIC  parts  will  not  be  used  initially,  since  DARPA  is 
interested  in  developing  scalable  designs  in  demonstrataole  form.  The 
parts  can  be  replaced  by  high  performance  parts  without  getting  VHSIC 
on  a  critical  path. 

Work  is  starting  on  gallium  arsenide  for  hardened  technologies  and 
that  will  support  space  applications.  Architectures  which  are 
developed  in  other  parts  of  the  strategic  computing  program  will  be 
compatible  with  gallium  arsenide.  That  will  provide  another  level  of 
integration.  That  is,  the  multiprocessor  architectures,  which  are 
developed  with  more  conventional  technologies,  can  also  be  used  in 
space. 

Performance  goals  for  Strategic  Computer  Program,  ghich  were 
worked  up  over  a  year  ago,  are  as  follows.  By  1990,  10 
logical  inferences  per  second  which  can  be  thought  of  as  rule  firings 
per  second  in  an  expert  system.  Proposal  are  in  place  for  very  fine 
mesh  architectures,  involving  millions  of  processors  which  can  meet 
those  goals.  They  are  a  little  risky  to  build  so  they  will  be  built  in 
smaller  forms,  software  will  be  developed  for  them  and  plans  for 
application  will  be  developed. 

Major  goals  for  Strategic  Computer  Program  are  to  develop  machine 
intelligence  technology.  Three  representative  (but  not  the  only 
possible)  applications  areas  have  been  selected  each  representing  a 
different  class  of  system.  The  battlefield  management  application  is 
the  support  of  a  large  enterprise  with  intelligent  systems.  The  pilot 
associate  is  essentially  a  one-on-one  system  supporting  one  human  doing 
a  stressful  task.  The  autonomous  system  is  one  that  operates  for  the 
most  part,  alone  with  direction  only  now  and  then  when  there  is  an 
opportunity  to  do  so.  The  battlefield  management  systems  prototype  is 
associated  with  the  Navy.  The  pilot  associate  is  an  Air  force  kind  of 
application.  The  autonomous  system  is  going  to  be  a  land  vehicle 
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since  land  is  the  safest  environment  tor  development  of  such  svstems. 

Supporting  these  are  some  intelligent  tunctions  sucn  as  real  time 
scene  analysis  for  vision  to  De  used  in  autonomous  vehicles.  Natural 
lanquage  navigation  in  expert  systems  in  another.  They  are  relatively 
generic  to  those  military  applications.  Supporting  them  are  the 
systems  architectures  such  as  siqnai  processing,  symDol ic  processing, 
architectures  for  the  rule  based  systems,  semantic  nets,  natural 
language  understanding  and  mul ti -function  machines  which  can  do  what 
these  architectures  can  do  but  not  as  rast.  inis  is  ail  going  to  be 
done  in  a  rich  infrastructure  on  the  ARpanE I  with  rapid  fabrication 
capability  and  first  quality  machine  resources  for  the  researchers 
involved. 

I  he  autonomous  vehicle  requires  development  of  new  vision  and 
navigation  systems  plus  stressing  such  thinqs  as  planning,  speech 
recognition,  information  fusion  ano  graphics.  Battlefield  management 
system  is  stressing  expert  systems  natural  language  exploitation  and 
speech. 

The  near  term  intelligent  functions  whim  are  expected  to  emerqe 
are  in  division  speech,  understanding  natural  lanquage,  and  expert 
system  areas.  The  corresponding  architectures  to  support  them  like 
systolic  arrays  and  some  signal  processing  functions  in  the  vision  and 
speech  areas. 

Later  there  will  be  system  architectures  Co  support  additional 
functions,  lhere  will  be  demonstrations  every  couple  of  years. 
Prototyping  will  be  done  on  top  or  existing  technologies  which  wi l l  oe 
the  benchmarks  for  development  ot  later  architectures  followed  by  test, 
selection  of  the  best,  ano  rapid  insertion  ot  elements  to  form  a  new 
level  of  intelligent  system  prototyping. 

Mr.  Berlin 

It  appears  that  Cray  and  UAPPA  are  doing  comoietely  difrerent 
things  and  confusion  may  have  arisen  in  thinking  ot  the  DARPA  program 
as  a  supercomputing  project. 

Much  of  this  presentation  will  oe  based  upon  the  significant 
problem  of  the  acquisition  of  technology  when  it  comes  off  the  line. 
Many  think  of  supercomputers  as  very  large  number  crunchers,  used  in 
research  and  development,  borne  may  ask  why,  in  MILLUM  III,  super 
computers  are  beinq  discussed  and  why  is  Cray  Research  here  discussing 
them.  The  issue  centers  on  now  can  we  leveraqe  technology  that  is 
going  to  be  developing  in  the  future  to  make  it  acccssable  -  technology 
insertion  if  you  will. 

Supercomputers  are  tnought  ot  as  very  large,  hardly  able  to  tit 
into  an  airplane,  and  with  just  one  problem  -  to  miniaturize  it.  Very 
seriously,  there  will  not  be  a  supercomputer  on  a  chip.  It  is  not  that 
very  dramatic  processing  on  a  chip  will  not  be  developed  but  because  a 
supercomputer  by  its  very  nature  ano  essence  is  going  to  be  the  most 
advanced  and  high  speed  processor  mat  we  can  muster,  if  we  can  put  a 
super  computer  on  a  single  emp  we  are  going  to  want  to  put  ten  of  them 
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together.  That  is  what  we  should  do.  But  there  always  has  to  be 
focusing  on  what  it  is  that  can  be  brought  to  bear  in  terms  of  a 
max i mum  comput i ng  env i ronment . 

Here  are  some  trends  that  are  happening  in  supercomputers  and  some 
things  that  could  have  an  impact  on  them  in  the  1990's. 

Looking  at  the  very  high  speed  processors,  there  does  not  appear 
to  be  any  guarantee,  or  even  high  probability,  that  these  processors 
will  be  inserted  into  the  operational  military  environment.  That  is 
not  because  they  shouldn't  be  but  because  we  have  not  faced  the 
challenge  of  how  to  take  technology  that  is  off  the  shelf  or  coming  off 
the  shelf,  and  without  creating  a  special  program  or  weapons  system 
program,  evaluate  and  insert  it.  It  cannot  be  done  when  the  product  is 
at  the  end  of  its  life  cycle.  A  way  is  needed  then  of  pro-actively,  if 
you  will,  looking  to  see  where  things  are  going  in  the  new  technology. 

If  that  challenge  is  not  met  there  will  be  the  situation  as  it  is  today 
where  certain  companies  like  Cray  Research  are  pressing  on  to  the  goals  of 
always  developing  the  fastest  possible  computer  while  other  companies 
in  the  industry  are  pressing  on  to  the  goal  of  fast  processors  that  fit 
into  a  certain  environment,  having  already  geared  up  to  programs  and 
program  requirements.  It  is  a  challenge  with  no  certain  answers  and 
issues  of  great  difficulty.  Post  1990  we  are  going  to  have  commercial 
products  avaiable  for  insertion  and  we  will  have  to  face  those  issues. 

Looking  back  to  past  work  in  supercomputers,  fernbach  calls 
supercomputers  the  bow  wave  of  the  computer  technology  ship.  That  is 
overstating  it  a  bit  because  the  computer  ship  has  many  technologies. 

The  strategic  computer  presentation  points  out  the  breadth  of 
technologies.  Traditionally  (supercomputer  builders)  have  said  they 
could  make  a  certain  processing  speed  at  the  supercomputer  level  with 
accompanying  requirements  of  stability,  floor  space,  cost  etc.  The 
users  say  they  would  like  to  have  this  processing  capability  for 
program  X  but  cannot  afford  to  pay  those  costs.  So  the  user  moves  down 
the  processing  scale  until  he  gets  to  a  cost  he  can  meet.  That  may  be 
oversimplified  but  in  one  sense  it  may  be  a  valid  approach. 

There  are  reasons  for  having  to  look  at  supercomputing  in  the 
military  environment.  First,  the  current  application  demand  - 
synthetic  aperture  radars,  high  speed  signal  processing  and  others. 

Some  applications  are  challenging  the  capability  of  the  available 
machines  and  the  assumption  is  made  that  they  are  all  that  is 
available.  So,  one  result  is  to  lash  4  or  S  or  10  or  20  of  them 
together  and  pay  the  software  costs  to  take  a  very  large  processing 
problem  and  spread  it  out  over  many  processors.  That  is  called  but  is 
not  true  distributed  processing  which  is  a  scheme  to  take  care  of  a 
number  of  applications.  The  multiple  use  of  computers  cited  above  is  a 
"contingency  plan"  because  what  is  needed  is  not  available.  Additional 
requirements  such  as  directed  energy  programs  and  changes  in  the 
(military  operational)  environment  which  are  in  view  but  not  yet  known 
or  defined.  Survi vibi 1 ity  requirements  are  increasing  for  which  one 
suggested  solution  is  putting  major  systems  on  vans.  Cost  constraints 
are  obvious  and  cost  performance  will  be  more  and  more  of  a  factor. 
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Fine  key  trends  in  supercomputing  can  be  identified.  We  know 
about  signal  processor  performance  both  in  microprocessing  and  in  high 
speed  processing.  Both  are  going  to  be  components  of  different  types 
of  supercomputing  architecture.  Next  is  dramatic  increases  in  1/0 
Oanwidth.  Production  channels  of  10  gHz  per  second  are  already 
accredited  and  these  are  being  shipped  in  everyday  systems  by  Cray  now. 
It  is  a  very  significant  problem  both  internally  and  externally.  Third 
is  parallelism  is  being  looked  at  from  two  different  approaches.  First 
is  small  amounts  of  parallelism,  each  processor  being  very  very  fast. 
Second  is  massive  parallelism,  each  processors  being  relatively  slow. 

The  software  problems  for  the  latter  are  much  more  difficult  than  for 
the  former.  Third,  unfortunately  the  software  problems  for  either  have 
not  been  solved.  That  is  a  limiting  technology  that  needs  examination, 
not  only  in  terms  of  operating  systems  and  multi-tasking  but  also  a 
very  serious  problem  in  terms  of  algorithms.  If  these  processors  were 
available  today,  we  would  not  know  how  to  use  them.  Fourth,  Cray 
Resesarch  is  looking  at  two  basic  technologies.  The  Cray  3  will  be 
built  out  of  gallium  arsenide.  Cray  Research  has  its  own  gallium 
arsenide  facility  which  started  in  May  1983  and  just  produced  its  first 
circuit  last  month.  The  test  chips  for  design  of  the  system  is 
expected  by  the  end  of  1984.  It  is  a  very  agressive,  and  turning  out 
to  be  quite  successful,  undertaking.  The  second  is  dense  memories. 

Cray  Research  is  constrained  by  something  a  lot  of  people  are  not  -  it 
needs  very  fast  dense  memories.  Cray  Research  cannot  afford  to  have 
nanosecond  gate  times  -  it  needs  picosecond  gate  times  and  lots  of  them. 
It  is  a  limiting  technology  and  for  that  reason  Cray  Research  has  built 
its  own  facility.  The  fifth  trend  is  compaction.  To  illustrate,  the 
CDC  6600,  which  was  the  supercomputer  of  its  day  took  about  100  square 
feet  or  less  of  floor  space.  The  performance  curve  linking  C0C  6600, 

CDC  6700  and  Cray  XMP  shows  the  latter  100  times  the  power  of  the  6600 
on  an  expontential  curve.  The  interesting  thing  is  that  the  floor 
space  and  facility  requirements  have  stayed  about  the  same.  The  XMP 
has  almost  the  same  basic  facility  requirements  as  the  VAX.  The  CRAY  2 
will  take  about  16  square  feet  and  will  be  another  step  in  performance. 
The  gallium  arsenide  machine  will  take  even  less  than  that.  The  reason 
is  not  an  attempt  to  compact  but  one  of  the  main  ways  to  get  speed  is 
to  put  things  closer  together.  Cray  Research  expects  that,  in  1990, 
the  CRAY  4  (or  whatever)  supercomputers  will  not  be  on  chips  but  in 
very  small  boxes.  That  has  serious  implications  for  the  trends  of 
(system  tasks  and  functions)  that  will  be  (in  work)  then. 
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This  slide  depicts  the  VLSI  growth  in  terms  of  the  number  of 
transitors  on  a  single  die  of  silicon  with  time.  An  exponential  growth 
in  complexity  has  taken  place  since  the  invention  of  the  integrated 
circuit  in  1958  up  through  today  and  it  is  continuing.  This  is  not  the 
only  progress  that  is  being  made  in  the  field,  The  other  progresses 
are  important  and  will  be  addressed  later. 

The  outgrowth  of  the  exponential  curve  is  snown  on  this  slide. 


INCREASING  DENSITY 

•  What  are  we  going  to  do  with  this  capability  in 

THE  COMMERCIAL  WORLD? 

•  What  will  the  performance  be? 

•  What  underlying  problems  are  there? 

•  WHAT  alternative  do  we  have? 

•  How  FAR  CAN  WE  GO? 


These  are  all  pertinent  questions  because  things  don't  increase 
exponentially  in  nature  forever.  Somehwere  it  ends.  The  other 
progresses  in  the  conventional  semiconductor  integrated  circuit  area 
have,  perhaps,  in  many  ways  as  significant  an  impact  at  the  systems 
level  as  the  core  device  itself  does.  One  is  in  a  very  mundane  area 
called  discrete  devices  which  are  thougnt  of  as  single  transistors  in  a 
single  can  that  turn  power  on  and  off.  One  such  is  an  interesting 
technology  called  smart  power  -  tnat  technology  which  enables  the 
handling  of  hundreds  of  volts  with  50  to  100  amperes  of  current,  which 
protects  itself  automatically,  and  which  carries  out  a  number  of  very 
interesting  interface  functions  that  must  be  gone  through  to  interface 
the  kernel  of  the  system  (represented  by  this  processor)  to  the  real 
world  through  some  sort  of  a  physical  transducer. 

Another  interesting  thing  is  the  ability  to  put  power  and  bi-polar 
circuits  on  the  same  die  with  the  MOS  processor.  As  to  speed,  silicon 
is  down  to  100  picoseconds  and  appears  to  be  qoing  still  lower. 

Gallium  arsenide  is  thought  of  as  a  speed  technology.  A  number  of 
other  things  are  going  on  and  these  all  are  happening  in  addition  to 
the  increasing  complexity  issue. 

Increasing  complexity  implies  the  capability  to  perform  complex 
logical  and  memory  operations.  Traditionally,  they  started  out  in  the 
form  of  SSI  and  MSI  and  they  were  the  standard  logic  fami ly.  They 
became  the  microprocessor  and  the  dynamic  RAM  and  various  kinds  of 
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peripheral  circuits.  Then  appeared  some  semi-custom  circuits  that 
tended  to  be  programmable  logic  arrays  and  gate  arrays.  The  technology 
is  developing  into  an  area  and  an  era  in  which  a  significant  part  of 
the  business  is  going  to  be  some  sort  of  custom  integrated  circuit  - 
probably  the  structured  custom  integrated  circuit. 

The  trends  that  were  started  by  the  standard  high  volume  part  - 
the  SS I —MS I  logic  family  like  TTL  and  so  on  -  were  taken  up  eventaully 
by  the  microprocessor  or  the  microcomputer. 

That  trend  will  continue  with  the  caveat  tnat  there  will  be  some 
additional  kinds  of  processors  -  not  general  purpose  but  tailored  to  do 
such  things  as  signal  processing  and  a  number  of  other  major 
identifiable  uses.  Microprocessors  of  today  are  similar  in 
architecture  and  performance  to  mini  and  super-mini  computers,  ihe  32 
bit  processors  in  design  in  most  companies  including  MOTOROLA,  have  a 
performance  level  comparable  to  a  VAX  11/780  on  one  chip. 

Microprocessor  development  is  going  to  continue  along  the  lines  of  the 
high  performance  mainframes  pioneered  by  CDC,  Cray,  IBM,  UNIVAC  and  a 
variety  of  other  kinds  of  standard  machines.  I  hat  has  broken  the 
architectural  water  for  it.  Some  new  architectures  will  be  added 
because  there  will  be  some  additional  capabilities  (needed)  but  tney 
will  be  limited  to  functional  processors.  Multi-processing  is  going  to 
come  to  commercial  VLSI  just  as  it  was  predicted  to  come  to  the 
supercomputer  a  few  moments  ago.  It  will  come  on  one  or  several 
chips.  The  exact  architecture  remains  to  be  developed  but  it  is  going 
to  come. 

Usage  -  ability  to  apply  it  -  is  going  to  oe  a  real  problem. 
Complex  chips  of  the  future  -  custom  chips  -  will  be  developed  using 
standard  macro-blocks  which  consist  of  todays  MPUs  only  they  will  oe 
core  function  where  the  designer  will  festoon  about  those  core 
functions  things  such  as  memory,  input/output,  other  peripheral 
functions  and  the  glue  necessary  to  make  this  operation  take  place. 

One  reason  for  a  standard  block  is  that  it  eases  the  software 
development  problem.  We  cannot  afford  to  write  new  software  tor  every 
new  architecture  that  comes  along  or  somebody  gets  a  hot  idea  to  design 
a  new  chip. 

The  rev i va I -meet i ng  nature  of  the  previous  discussion  of  software 
(at  this  seminar)  was  impressive  as  are  the  acconio) 1 shments  of  Augusta 
Ada  Lovelace.  One  thing  that  needs  to  be  looked  at  in  the 
microprocessor  business  is  to  look  at  a  still  more  advanced  standard  as 
indicated  on  the  next  slide. 
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Software  is  beginning  to  be  a  major  issue  for  those  in  the  VLbl 
business.  For  years  it  has  not  been  just  a  Question  of  putting 
transistors  down  on  silicon  but  a  Question  of  architecture  and  of  some 
very  substantial  software  problems  in  figuring  out  how  to  apply  those 
machines.  That  can  be  fitted  on  a  single  chip  of  silicon,  lhe 
organization  of  a  lot  of  these  (chips)  is  going  to  be  unique  and  they 
will  be  functionally  oriented. 

Performance »  in  general ,  is  going  to  improve  some  of  which  15 
automatic  as  size  of  devices  shrink.  The  device  man's  index  of 
performance  is  delay  power  product  (DPP)  which  is  roughly  proport ia I  to 
the  dimension  of  the  device  cubed  so  that  something  half  the  size  of 
its  predecessor  will  have  8  times  the  performance  in  OPP.  Delay  power 
product  is  related  to  the  function  throughput  rate  (FIR)  earlier  used 
as  the  index  of  performance  for  VHS1C.  FTP  was  thought  to  be  basically 
an  unuseable  figure  of  merit  in  the  device  business.  It  turns  out  to 
be  a  constant  times  the  power  dissipated  on  the  chip  (which  has  been 
constant  for  quite  some  time)  divided  by  the  delay  power  product.  That 
presupposes  significant  improvements  of  the  order  of  10  to  20  in 
function  throughput  rates  over  where  we  are  now. 

One  thing  that  is  very  important  as  shown  on  this  next  slide. 
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Nanosecond: 

A  Billionth  of  a  Second l 


Gate  delays  are  expressed  in  current  parlance  in  nanoseconds.  A 
physicist  might  tend  to  think  of  one  nanosecond  as  a  unit  of  length  - 
one  light  foot  (11.82  inches).  It's  meaning  in  terms  of  performance  of 
machines  is  shown  on  the  next  slide 
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As  time  has  gone  on,  the  signal  path  length  in  amputers  has  gone 
from  125  feet  in  1948  to  20  feet  in  1980.  Reducing  that  path  length  is 
the  greatest  contribution  VLSI  can  make  for  the  world  of  computing. 
Getting  more  on  the  die,  even  though  the  gates  might  not  go  faster,  is  a 
considerable  improvement  in  performance  just  because  gates  are  closer 
together. 

Underlying  problems  are  shown  on  the  next  slide. 
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The  first  of  these  is  the  issue  of  device  physics.  As  device 
sizes  shrink  the  power  supply  voltage  has  to  go  down  because  as  two 
points  get  closer  and  closer  together  for  any  given  voltage,  there  will 
eventually  be  a  breakdown.  That  happens  when  devices  become  less  than 
one  micron.  Supply  voltages  which  have  been  more  or  less  standard  at  5 
volts  will  have  to  go  down  to  3,  2.5,  2  or  something  over  l  volt. 
Minimum  dimensions  of  MOS  devices  are  shown  on  the  next  slide. 

MINIMUM  DIMENSIONS  OF  MOS  DEVICES 
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Interconnections  is  related  to  device  physics.  Contact  resistance 
goes  as  area  not  as  size.  Making  contract  witn  these  devices  is  going 
to  be  a  significant  problem.  Similarly  it  can  be  proven  that  the  RC 
products  of  the  lines  that  interconnect  transistors  on  a  die  increase 
as  the  size  shrinks.  Because  of  second  order  effects,  it  is  expected 
there  will  be  a  lot  of  cross-talk.  Reliability  of  interconnects  must 
be  seriously  looked  at.  Interconnects  are  a  very  important  problem 
because  30  to  70  percent  of  the  die  area  is  space  with  nothing  but 
metal  going  from  one  place  to  another.  Getting  the  interconnect  size 
down  is  the  most  significant  thing  that  can  be  done  to  reduce  the  die 
size. 


Packaging  is  related  to  the  roregoing  problems.  Packaging  is  P  to 
the  fourth  power  times  R-Pins,  Power,  Performance,  Price  and 
Reliability.  Ihe  current  standard  is  in  the  vicinity  of  100  pins.  Yet 
customers  ask  for  functions  that  have  200,  250  or  even  300  inputs  and 
outputs.  These  cannot  be  handled  with  existing  packages.  Power 
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dissipation.  The  function  throughput  rate  is  the  quotient  of  two 
numbers  -  the  delay  power  product  into  the  power  dissipated  on  the  die. 
The  fastest  way  to  increase  the  performance  of  systems  is  to  increase 
the  power  dissipation  capability  of  the  packaging  by  two  orders  of 
magnitude.  It  is  a  lot  less  expensive  then  building  $I00M  factories  to 
build  sub-micron  devices.  We  have  to  do  both  if  we  are  going  to 
squeeze  the  maximum  out  of  the  technology.  Packaging  is  the  biggest 
unsung  area  of  future  improvement  that  exists  in  the  technology  today. 
If  we  don't  do  it  someone  else  is  going  to  find  a  way  to  solve  the 
packaging  problem  better  than  we  have  with  the  dual  in-line,  the  small 
outline  and  other  package  configurations  that  are  standards  now. 

The  next  subject  is  testing,  borne  examples  are  shown  on  the  next 
slide. 
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I.  INCREASE  TEST  SYSTEM  SPEED  AND  COMPLEXITY  TO  KEEP  PACE  WITH  VLSI 
CLOCK  RATE,  WORD  LENGTH,  AND  PIN  COUNT. 

II.  MAINTAIN  LOW  VLSI  TEST  TIME  BY  PROVIDING  ON-CHIP 

•  SELF-TEST  AND  DIAGNOSTIC  FIRMWARE 

•  PRIVILEGED  TEST  INSTRUCTIONS  IN  INSTRUCTION  SET 

•  SPECIAL  TEST  AND  READOUT  PATHS  TO  CRITICAL  AREAS 
OF  CHIP,  E.G. : 

MEMORY  COUNTERS  MULTIPLIERS 

REGISTERS  ADDERS  CONTROL 

•  MODULARIZATION  OF  LOGIC  AND  MEMORY 

III.  TRADE-OFF  INCREASED  DEVICE  COUNT  FOR  REDUCED  TEST  TIME 


Turning  to  complex  integrated  circuits,  one  thing  it  does  is  that 
it  is  one  of  the  answers  to  the  technology  drain.  If  everything 
becomes  a  complex  integrated  circuit,  there  is  not  enough  manpower 
around  to  copy  them  and  duplicate  them  in  functions  of  the  same  kind. 
Since  they  are  functionally  specialized,  there  are  much  more  difficult 
problems  in  applying  them.  These  advantages  are  interesting  from  a 
military  standpo i nt . 

There  are  problems  in  computer  aids  to  design.  The  next  slide 
shows  a  significant  problem  with  design  cycle. 
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The  bottom  sector  shows  the  time  it  took  to  design  a  system  from 
conception  all  the  way  through  working  hardware  by  a  major  manufacturer 
using  SSI.  The  cross-hatched  section  is  component  selection  and 
design.  The  supper  sector  is  LSI  design  cycle.  Although  the  total  has 
become  shorter,  the  cross-hatched  portion  has  become  longer  and  is  a 
much  larger  proportion  of  the  total  cycle.  As  the  industry  goes  to 
VLSI  the  problems  represented  here  are  going  to  come  back  on  the 
commercial  manufacturers  and  the  pressure  will  be  on  to  solve  those 
prob I ems . 

There  is  the  significant  problem  of  economics,  it  costs  between 
$b0  and  $4l)U  million  to  build  a  factory  to  make  VLSI  and  no  abatement 

is  in  sight.  Unless  the  ability  of  the  equipment  to  produce  more 

circuits  in  less  time  using  less  floor  space  improves,  there  is  a  big 
problem  in  economics.  In  the  final  analysis,  it  may  be  the  ultimate 
problem. 

The  alternatives  are  shown  on  the  next  slide. 

ALTERNATIVES: 

•  Other  Semiconductors  (GaAS.  Iff,  sos) 

t  Other  Devices  (J-J's.  Bio,...) 

t  Wafer  Scale  Integration 

•  3D,... 

One  is  gallium  arsenide.  In  some  opinions  the  promise  of  gallium 
arsenide  is  considerably  more  limited  than  that  of  silicon  for  reasons 
of  density  and  compaction.  It  is  good  for  optical  interconnects,  high 
frequency  fron  ends  where  low  noise  figure  is  an  important  issue,  for 
high  frequency  efficient  power  amplification,  as  in  battery  powered 
equipment  and  in  certain  types  of  microwave  monolithic  integrated 
circuits  gallium  arsenide  will  be  the  material  of  choice.  It  will  not 
be  the  material  of  choice  for  large,  very  complex  die.  The  integrated 
circuits  of  gallium  arsenide  will  tend  to  be  simpler  but  very  high 
speed  functions. 

Wafer  scale  integration  is  one  means  of  solving  a  complex 
packaging  problem  -  to  get  more  tnings  closer  together  so  that  path 
lengths  are  smaller. 

Josephson  Junction,  biotechnology  and  that  kind  of  thing  have  not 
paid  off  to  the  extent  that  they  look  like  general  commercial  VLSI  made 
of  s i I i con . 

Three  dimensional  is  probably  where  going  beyond  the  planar 
technology  lies.  There  will  be  devices,  stacked  one  on  top  of  the 
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other.  Using  the  third  dimension  is  probably  the  best  bet  we  nave. 
When  we  run  out  of  three  dimensions  we  will  really  have  a  problem. 


The  final  question  is  how  far  can  we  go? 

HOW  £AS- CAN  ML.  60? 

•  TO  1/2  MICROMETER,  AT  LEAST 

•  Unknown  problems  with  smaller  devices 

•  Significant  improvements  are  possible  with  proper 
packaging! 


Certainly  the  technology  exists  to  get  to  a  half  micron  -  unlikely  in 
two  years;  3  or  4  years  is  a  better  bet.  lhere  should  be  a  megabyte 
RAM's  in  the  I990's  -  a  lot  of  memory  in  a  very  little  space  but  there 
are  no  fundamental  technical  problems  keeping  us  from  getting  there. 

Beyond  the  half  micron  level  and  that  level  of  complexity  there  are 
some  real  fundamental  problems.  JD  is  a  possible  answer.  The  real 
answer  will  be  the  animal  cunning  of  those  who  succeed  us  working  in 
VLSI.  The  old  Chinese  curse:  "May  you  be  condemned  to  live  in 
interesting  times"  certainly  applies  to  us  in  the  commercial  VLSI 
business.  It  is  a  technology  which  is  emerging  and  will  continue  to  do 
so  at  least  for  10  more  years.  To  take  a  defensive  strategy  and  try  to 
keep  others  from  getting  the  technology  is  less  important  then  to  try 
to  maintain  a  good  offense,  to  push  the  technology  as  fast  as  we  can 
and  keep  ahead  of  the  pack. 

The  following  points  were  made  in  answers  to  questions,  comments 
and  responses: 

...  In  considering  the  Strategic  Computing  Program,  the  programs  all 
go  from  the  idea  down  to  the  chip.  Tools  do  not  exist  to  go  the 
other  way.  If  there  is  an  attempt  to  steal  a  system  and  we 
produce  better  and  better  means  of  producing  systems,  they  have 
to  learn  what  we  did  to  do  the  one  they  want  to  steal,  so  we 
would  already  be  ahead.  Seems  more  of  an  espionage  problem  rather 
than  a  technological  problem.  The  question  is  not  to  reverse 
engineer  a  single  chip.  If  a  lot  of  chips  are  custom  and  there  is 
no  longer  a  large  number  of  standard  part  types,  the  number  of 
chips  that  have  to  be  reverse  engineered  becomes  overwhelming. 

...  Ada  was  not  designed  for  artificial  intelligence  although  it 
has  a  number  of  nice  features  (for  Al).  Researchers  should  do 
research  with  the  tools  that  suit  them  best.  If  LISP  and 
MACLISP  and  PROLOG  are  useful  in  doing  demonstrations  of  Al 
concepts,  that  is  what  they  were  designed  for.  If  the  purpose 
is  to  build  an  Al  system  like  a  mission  critical  system  with 
documentation,  testing  and  reliability  that  is  what  Ada  was 
designed  for.  Ten  years  from  now,  we  may  be  able  to  build 
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mission  critical  systems  with  LISP- 1  ike  derivatives  of  that  time. 
But  in  ten  years  when  we  will  be  getting  artificial  intelligence 
into  our  weapon  systems,  there  may,  and  probably  will  be  different 
ways  of  developing  those  programs  than  the  languages  we  have  now. 
In  the  Strategic  Computing  Plan  first  years  Ada  and  LISP  environ¬ 
ments  are  called  out  for  the  multiprocessors  which  will  emerge. 

It  is  recognized  that  Ada  is  a  qood  thing  to  use  and  it  will  be 
used  to  the  maximum  extent  possible,  fhere  are  some  things  the 
A l  researcn  community  doesn't  like  about  Ada  and  no  attempt  will 
be  made  to  jam  it  down  their  tnroats.  The  kind  of  systems  which 
will  be  developed  using  the  LISP  environments  will  perhaps  be 
very  large  scale  systems  and  they  will  have  to  face  the  large 
scale  software  engineering  problems  which  Ada  verv  well  addreses. 
it  would  not  be  surprising  to  see  that,  about  five  years  from  now, 
there  may  be  a  convergence  of  Ada  and  LISP  into  some  refined 
version  of  Ada  which  supports  A I  very  nicely. 

A  revision  of  Ada  standards  is  anticipated  in  1988.  One  of  the 
things  which  was  avoided  in  the  study  for  Congress  was  the  evolu¬ 
tion  of  Ada  because  it  was  felt  the  program  had  a  signficantly 
long  life  so  it  was  not  a  matter  for  concern.  It  we  look  IS  to 
20  years  ahead  it  wi I  I  be  natural  to  see  Ada  not  only  evolving 
to  future  versions  of  standard  but  also  become  a  language  like 
COBOL  or  FORTRAN  in  very  wide  popular  use  but  one  that  is  not 
representing  the  thinking  of  the  day.  bo  something  like  that 
should  be  anticipated  and  dealt  with  somewhere  along  the  road. 
There  is  enough  of  a  technology  base  in  the  language  area  in  this 
country  so  it  should  not  be  a  problem.  New  directions  will 
emerge  and  advantage  will  have  to  be  taken  of  them  when  they 
emerge. 

U.K.  experience  with  an  MOD  standard  language,  CORAL  66,  shows 
it  takes  a  long  time  to  get  it  established  and  one  of  the  pro¬ 
blems,  both  hardware  and  software,  is  assurance  that  the  com¬ 
pilers  will  produce  effective  and  "safe"  code.  The  theme  of 
these  discussions,  both  hardware  and  software,  is  toward  in¬ 
creasing  complexity  and  size  of  capabi 1 itv  which  is  excellent. 

A  price  seems  to  have  to  be  paio  in  difficulty  of  assurance  that 
the  result  is  what  people  believe  it  is.  The  (Dr.  Howard)  slide 
on  testing  addressed  this  point  to  one  or  those  major  problems. 
Testing  from  the  standpoints  both  of  design  verification  and 
minimum  test  vector  spaces  required  to  thoroughly  check  out 
all  the  states  of  the  machine  so  that  it  is  kown  that  there 
isn't  a  hidden  flaw  in  it.  This  is  a  major  problem  which  is 
not  getting  solved.  There  may  be  a  catch  in  this  whole  thing 
that  this  (assurance)  problem  is  unsolvable.  The  same  applies 
to  software  with  its  lavers  of  support  software,  bui id  stan¬ 
dards  and  so  on.  One  advantage  in  building  a  VLbl  cnip,  and 
there  may  be  a  software  analogue,  before  it  is  put  in  a  package, 
it  may  be  possible  to  get  probes  inside  the  circuit  that  may 
not  be  accessible  at  the  outset.  So  there  may  be  ways  of  dividing 
the  problem  into  smaller  more  soluble  problems.  The  chart  was 
intended  to  show  that  there  are  several  ways  of  getting  (this 
capability).  One  is  to  increase  the  speed  at  which  testing  goes 
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but,  because  of  speed  problems  it  Is  an  unlikely  alternative. 

A  second  Is  soft  test  and  diagnostic  firmware  actually  emoedded 
In  the  die  Itself.  Tne  compoents  will  check  themselves  out  and 
signal  the  outside  world  that  check  has  been  made  and  they  are 
ok.  Built-in  test  is  the  currently  popular  term  for  it.  Another 
would  be  a  privileged  set  of  instructions  so  someone  outside  can 
reconfigure  the  machine  along  the  lines  of  separation  of  memories 
the  registers,  the  counters,  the  processors  and  so  on  and  test 
them  separately  -  a  modularization.  The  final  way  Is  stop  ad¬ 
vancing  complexity  because  It  cannot  be  tested  and  it  is  to  be 
hoped  this  does  not  turn  out  to  be  the  case. 

Another  point  on  using  Ada  as  a  focus  for  (OSD)  activities. 

There  has  been  considerable  Interest  In  the  computer  science 
community  about  formal  definition  of  programming  languages  and 
formal  methods  for  deriving  software  systems  so  that  It  could  be 
assured  that  as  the  software  development  process  progresses  from 
step  to  step  that  (each  step)  would  be  done  in  an  error-free  way. 
There  are  very  few  people  who  have  the  background  to  adequately 
address  that  problem,  and,  in  many  ways,  their  energies  have 
beon  dissipated  in  discussing  toy  systems.  The  EEC  along  with 
the  Ada  Program  Is  sponsoring  work  In  the  formal  definition  of 
Ada  and  formal  methodologies  to  see  If  that  kind  of  work  cannot 
be  pushed  In  assuring  the  correctness  of  every  step  to  cover 
a  full  programming  language  of  the  complexity  of  Ada  -  stage  to 
stage  transition  In  an  error  free  way. 

This  last  approach  may  be  solving  the  wrong  problem  exactly  right. 
In  the  large  complex  military  system  with  software  the  requirements 
keep  changing  continuously  at  the  front  end.  They  are  not  well 
specified  and  as  one  goes  three  to  four  to  five  years  downstream 
In  a  software  development  project,  even  though  perfect  tools, 
perfect  testing  and  so  on  are  available,  the  end  result  may  not 
be  what  Is  really  wanted  and  It  may  not  be  known  as  the  project 
progresses.  Until  that  whole  process  is  fully  automated  and 
have  ways  of  going  both  directions  -  requirements  all  the  way  to 
code  -  project  people  cannot  be  assured  It  is  correct. 

The  program  development  process  starts  at  the  top  with  a  decision 
to  build  something.  The  process  proceeds  down  a  decision  tree 
where  decision  Is  made  at  each  stage  to  do  something  and  It  moves 
to  lower  and  lower  stages,  implementing  the  decisions  above  It. 

A  lot  of  manual  work  is  Involved  in  each  decision  step.  OSO/Ada 
Program  Office  would  like  to  automate  each  of  these  steps  In  such 
a  way  that  when  a  test  is  run  or  a  program  is  modified  the  point 
of  decision  tor  the  Item  to  be  changed  can  be  traced  back  (by  an 
expert  system  In  strategic  computing)  and  the  correction 
through  resulting  subdecisions  can  be  made. 

The  design  of  the  system  may  be  lost  and  the  knowledge  used  in 
developing  the  concret  code  may  not  be  available  in  explicit 
form.  It  It  woro  captured  automatically  there  would  be  an 
explicit  representation  of  the  design. 
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DR.  LYON 


Opened  Session  III  with  the  intention  to  cover  four  things. 

Hirst  is  the  context  of  MILCOM  111  and  Session  111.  M1LC0M  I  and 
II  were  conducted  without  knowing  how  far  and  long  it  would  take  to 
qet  some  issues  clarified  but  it  appears  that  they  are  beginning  to 
pay  off.  from  initial  stresslnq  of  differences,  through  identification 
of  some  elemets  of  partnership,  the  concern  was  then  whether  or  not 
enough  pieces  were  identified  and  properly  structured.  In  MIlLOM  Ml 
it  is  clear  that  there  are  a  number  of  activities  underway,  that  they 
can  be  related  mucn  better  and  that  dialogue  and  communication  must  be 
improved.  Yesterday  morning  users  were  asked  to  set  forth  the 
problems  of  the  future.  In  the  afternoon  response  in  meetinq  those 
needs  was  presented. 

This  morning,  leaders  in  their  communities  have  been  asked  what 
additional  needs  to  be  done  -  as  the  glue  between  those  islands  of 
activity.  In  the  area  of  politics  of  technology  it  needs  to  be 
stressed  that  the  U.S.  is  regarded  as  underusing  its  technology  while 
others  are  using  theirs  to  a  qreater  extent.  The  U.S.  has  a 
tremendous  technological  heritage  and  activity  but  there  is  a  question 
that  it  is  being  brought  to  the  national  security  interests  properly. 

The  second  point  is  that  the  Soviet  Union  does  not  have  a 
commercial  industry.  Iheir  leading  edge  technology  is  their  military 
and  it  nearly  all  goes  to  national  security.  It  determines  the 
fielded  capability  of  the  Soviet  Union.  Tne  U.S.  is  the  opposite  and 
its  commercial  marketplace  is  rolling  over  the  technology  every  two  or 
three  years.  It  must  be  captured  and  brought  to  the  Defense 
Department's  needs. 

Ihe  third  point  is  the  need  for  a  positive  attitude.  Ihe  general 
fault-finding  and  over-concentration  on  the  source  of  problems  does  not 
solve  them.  Constructive  ways  to  solve  problems  are  needed  and  they 
should  be  moved  forward  with  a  positive  approach.  There  Is  evidence 
of  that  beginning  to  happen  in  yesterday's  sessions. 

The  fourth  point  is  that  this  Session  III  will  be  talking  more 
about  leadership  than  management.  Some  perceive  that  there  is  a  broad 
attempt  to  manage  a  way  out  of  leadership  problems.  Leadership  is  not 
only  projection  of  the  leaders  will  but  creation  of  a  climate  fo~ 
innovation  by  subordinates  and  motivation  of  people  to  do  their  best  - 
not  just  a  passing  grade.  There  is  a  potential  in  the  U.S.  for  both 
good  leadership  and  good  management  and  it  must  be  tapped  in  the 
national  interest. 

An  attempt  was  made  to  get  people  in  this  session  who,  by  their 
sheer  physical  presence  and  commitment  to  principles  would  get  the 
rest  of  the  community  together.  They  will  be  addressing  an  audience 
that  as  middle  management  is  the  group,  as  much  as  any  of  the  country, 
that  gets  things  done.  If  they  are  convinced  things  will  change. 
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Senator  Bingaman 


Although  new  to  the  Senate  ana  the  sujoect  of  MILCUM  111,  Senator 
Bigaman  stated  his  awareness  ot  the  substantial  funds  going  into  this 
area  and  his  desire  to  pursue  the  subject  and  to  try  to  make  decisions 
on  an  intelligent  basis.  As  a  member  of  the  Armed  services 
committee,  I  am  aware  that  computer  technology  is  essential  to  this 
country  and  that  it  is  essential  that  we  reverse  the  trend  of  the 
diminishing  lead  we  have  in  this  area.  I  he  existence  of  this  seminar 
is  clearlv  testimony  of  the  need  for  novernment  industry  and  the 
academic  world  to  come  together  it  we  are  going  to  commend  ADPA  on 
havina  this  conterence  and  I  hope  it  is  an  event  that  continues  in  the 
vears  ahead. 

fwentv  years  ago,  as  you  know,  the  United  States  was  the 
undisputed  leader  in  computer  technology  in  the  world.  Our  European 
ana  Japanese  allies  were  emerging  from  post-war  reconstruction.  The 
Soviet  Union  lagged  far  behind  in  microelectronics  and  computer 
technology,  loday,  we  face  signficiant.  challenges,  particularly  from 
our  allies  in  the  commercial  world  and  from  the  Soviet  Union  with 
regard  to  tecnnoiogy.  Our  al les  are  challenging  us  for  the 
marketplace  in  the  sale  of  these  commercial  computer  capabi I ities. 

Over  the  last  twenty  years,  Japan  has  emerged  as  a  major  competitor  in 
this  market.  Japanese  industry  and  government  have  worked  together  to 
all  but  eliminate  our  lead  in  very  larae  scale  integrated  circuits, 
super-computers  and  some  other  areas.  The  national  supercomputer  and 
fifth  generation  computer  projects  in  Japan  are  clear  evidence  what 
the  Japanese  have  set  themselves  a  goal  of  achieving  superiority  over 
this  country  and  the  rest  of  the  world  in  these  technologies  by  tne 
I99l)'s.  The  remarkable  success  of  the  Japanese  semiconductor  industry 
during  the  last  two  decades  (is  a  challenge).  We  in  the  United  States 
obviously  have  to  take  the  challenge  seriously.  Similarly  the 
Japanese  are  moving  out  in  the  critical  area  of  software  development, 
were  they  have  lagged  behind  the  United  States.  They  are  now  making 
intensive  efforts  to  develop  an  automated  software  factory.  We  see 
similiar  efforts  in  Europe  both  nationally  and  in  the  context  of  the 
European  Economic  Community.  Tne  EEC  has  drawn  up  its  own  joint 
information  technology  research  effort  which  it  is  hoping  to  beam  in 
the  near  future.  This  proposal  envisions  a  five  year  program  with  a 
$1.3  billion  budget  to  cover  the  entire  spectrum  of  computer  related 
research  from  microelectronics  to  software  to  artificial  intelligence. 
This  would  complement  such  national  programs  as  the  $SUU  million 
British  micro-electronics  research  program  announced  last  year. 

The  guestion  is:  How  should  this  country  react  to  the  challenge 
from  abroad/  What  are  the  respective  roles  of  government,  industry  ana 
academia  in  meeting  the  challenge?  I  am  confident  that  we  can  meet 
the  challenge  and  that  we  wi l 1 .  in  recent  years  remarkable  changes 
have  been  made  in  the  private  and  public  sector's  efforts.  Industry 
has  rapidly  increased  its  research  budgets  and  denoted  more  attention 
to  building  infrastructure  for  the  Iona  haul.  The  Semiconductor 
Research  Cooperative  is  helping  hard-pressed  universities  to  expand 
their  basic  research  efforts  in  new  semiconductor  technologies. 
Micro-electronics  and  Computer  Corporation  with  a  projected  budget  of 
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$50-80  million  annually  will  work  in  generic  information  technologies. 
The  Defense  Department  has  launched  research  programs  to  improve  the 
technology  available  to  it.  The  Ada  Higher  Ordered  Language 
development  and  the  Very  High  Speed  Integrated  Circuit  program  have 
been  successes  by  all  accounts.  DOD  is  now  launching  its  Strategic 
Computing  initiative  and  the  STARS  program  and  these  promise  to  make 
substantial  contribution  to  future  weapon  systems  and  have  significant 
spin-offs  tor  the  private  sector.  1  understand  that  Mr.  Battista 
addressed  you  yesterday  and  gave  some  reservations  concerning  the 
strategic  computer  program  that  DARPA  has  indicated  it  will  try  to 
pursue.  1  agree  that  perhaps  additional  amplification  is  needed. 
Nevertheless,  I  think  that  proposal  and  similar  proposals  have  been 
very  useful  in  stimulating  discussion.  I  hey  will  undoubtedly  be 
highlighted  in  this  year's  fiscal  budget.  The  President  will  submit 
that  next  week  and  we  will  get  the  specifics  of  what  he  has  in  mind. 

One  question  i  would  have  about  the  STARS  program  is  whether  it 
will  do  enough  to  stimulate  basic  research  on  software  principles  at 
our  various  uni verisities.  The  proposal  on  the  Software  Engineering 
Institute  seems  to  be  more  applied  and  short  term.  To  quote  from  its 
description  "It  is  to  engineer  and  brinq  into  military  practice 
emerging  software  technology".  My  question  is  whether  it  would  be 
useful  to  complement  the  Software  Engineering  Institute  with  a  small 
basic  research  program  on  computer  software.  I  his  is  to  be  funded  at 
select  group  of  universities  on  a  fairly  modest  level.  I  have  in  mind 
the  model  of  the  Joint  Services  Eletronics  Program  which  has  made  so 
many  contributions  to  basic  electronic  semiconductor  research  since 
World  War  1 1 . 

Let  me  turn  back  to  the  major  question  before  us:  Does  tne  DUO  R 
&  D  computer  effort  and  the  much  smaller  efforts  of  the  civilian 
agencies  combined  with  the  massive  private  sector  spending  on  research 
and  development  al I  add  up  to  an  adequate  answer  to  the  cnallenge  we 
face  from  aboradV  1  am  not  sure  that  they  do  for  several  reasons. 

first,  I  am  concerned  that  we  as  a  nation,  and  just  on  the  policy 
level,  do  not  pay  enough  attention  to  the  education  of  the  students  in 
math  and  science  which  will  be  needed  to  man  these  efforts.  This  is 
not  a  problem  which  the  federal  Government  can  solve  alone.  It  is 
primarily  state  and  local  governments  which  must  improve  primary  and 
secondary  science  education.  But  the  Federal  Government  can  make  a 
difference  at  the  university  level  by  providing  research  support  and 
improved  Instrumentation  to  professors  and  research  assistant-ships 
and  fellowships  for  graduate  students.  Federal  programs  in  these 
areas  today  are  simply  in  my  view  not  commensurate  with  the  need. 

Both  the  military  and  our  society  as  a  whole  will  suffer  unless  the 
science  education  gap  which  exists  between  ourselves  and  our  principal 
competitors  is  not  narrowed. 

Secondly,  I  worry  about  the  fact  that  our  economic  competitors 
are  focusing  their  government  subsidies  almost  entirely  on  the 
civilian  sector  of  the  computer  industry  whereas  we  carry  the 
disproportionate  share  of  the  science  alliance  burden  in  developing 
military  computers  and  their  software.  For  carrying  that  burden  we 
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get  some  civilian  spin-offs  but  certainly  far  less  than  we  could  reap 
if  some  of  those  resources  were  devoted  to  civilian  applications.  At 
how  much  of  a  disadvantage  will  our  private  sector  firms  be  in  the 
long  run  and  do  we  run  the  danger  of  yielding  much  of  the  civilian 
market  to  our  subsidized  competitors  even  as  we  retain  world 
leadership  in  military  computer  technology?  On  the  other  hand,  would 
we  really  welcome  the  two-way  street  in  weapon  systems  which  would 
accompany  a  more  equitable  sharing  within  the  alliance  of  the  defense 
R  &  0  burden?  Or  do  we  need  separate  government  programs  to  spur 
computer  technology  for  civilian  applications? 

Some  would  argue  that  this  would  be  a  civilian  industrial  policy 
to  complement  the  military  industrial  policy  we  may  already  have  in 
this  area.  1  don't  have  the  answers  to  these  questions.  After  one 
year  in  the  Senate  I  am  still  just  trying  to  learn  the  questions.  1 
can  assure  you  there  is  a  bipartisan  consensus  in  the  Congress  on  the 
importance  of  computer  technology  to  our  national  security  and  to  our 
economic  competitiveness.  There  is  also  an  enthusiasm  among  members 
of  the  Congress  about  the  possibilities  that  future  computer 
technologies  will  create  for  our  nation.  1  don't  think  the 
relationship  of  the  Congress  with  D00  and  industry  needs  to  be 
adversarial.  1  gather  that  is  one  of  the  questions  that  has  been 
posed  for  this  panel.  You  can  question,  and  many  people  do  (Or.  Wade 
may  elaborate  on  this)  whether  Congress  needs  to  consider  in  the 
budget  process  the  level  of  detail  that  it,  in  fact  does  consider  in 
this  day  and  time.  We  do,  1  think,  tend  to  look  at  the  trees  and  not 
the  forest  and  at  the  short  term  and  not  the  long  term.  But  the 
reality  seems  to  be  that  at  least  90%  of  both  the  Armed  Services 
Committee's  and  Oefense  Appropriations  Sub-Committee's  time  is  devoted 
to  detailed  scrutiny  of  every  line  item  in  the  Budget  which  the 
Department  submits. 

This  year  l  am  committeed  to  being  one  of  those  scrutinizing  the 
computer-related  line  items  and  would  welcome  your  help  in  doing  that. 
I  would  also  welcome  your  suggestions  for  what  can  be  done  by  those  of 
us  in  Congress  who  are  attempting  to  be  helpful  and  constructive  on 
this  issue.  I  hope  that  we  can  all  say  in  ten  years  that  we  are  in  a 
better  position  vis-a-vis  the  Soviet  Union  and  our  economic 
competitors  because  of  decisions  we  made  today  and  discussions  we've 
had  at  this  conference  this  year. 

OR.  WADE 

Opened  by  expressing  appreciation  of  DOD  for  ADPA  conducting 
M 1 LCOli  symposiums.  He  stressed  the  great  importance  of  getting  people 
together  to  talk  through  these  kinds  of  problems,  returning  home, 
sharing  experiences  and  looking  toward  the  future  in  solving  these 
problems  which  are  so  important  to  the  national  defense  of  the  United 
States.  In  discussing  the  topic  of  DOD  relationship  to  Congress  Dr. 
Wade  set  aside  a  lengthly  prepared  treatment  in  favor  of 
focusing  on  a  couple  of  points  as  precursor  to  questions  and  answers. 

Previous  speeches  have  made  it  clear  that  software  items  are  now 
on  the  list  of  first  priorities  for  the  Department  of  Defense.  It 
was  not  always  so  and  DOD  feels  it  is  important  for  ADPA  to  impress 
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on  a  1 1  of  its  members  the  seriousness  which  officials  in  DOO  and  OS0 
see  the  problems  of  software  definition,  procurement  and  maintenance. 

The  word  maintenance  "in  the  case  of  software  actually  hides  the 
fact  that  in  data  processing  more  than  any  other  part  of  DOO 
activities,  there  is  a  need  for  continuous  evolution  of  (software) 
programs  to  take  into  accout  changes  in  geography,  doctrine,  threats 
and  most  important,  the  commander's  style.  Rephrasing  these  words  to 
convince  this  MI  LOOM  111  audience,  the  DOD  -  Industry  partnership 
needs  to  go  far  beyond  Ada,  VHSIC  and  SIARS  initiatives.  DOD  and 
Industry  must  together  find  a  way  to  express  and  particularly  Industry 
to  receive  a  clear  definition  of  what  those  in  the  Department  of 
Defense  need. 

The  word  "Requirements"  is  often  loosely  implied  and  used  to 
define  what  DOD  needs.  The  problem  with  software  requirements  can  be 
and  often  is  used  radically  in  the  wrong  way  in  the  context  of  trying 
to  compare  them  to  hardware  requirements.  An  example  from  the  area  of 
Command  and  Control.  It  would  be  utterly  unacceptable  for  DOD  to  have 
software  that  would  impose  on  the  Commander  a  style  that  is  really  not 
his  own.  In  this  case,  the  requirements  change  when  the  users  change, 
a  situation  which  occurs  very  seldom  with  specific  hardware.  This  is 
the  reason  why  software  maintenance,  if  properly  understood,  becomes  of 
great  importance  in  the  scheme  of  things  surrounding  the  software 
i ssue. 

Software  then  must  be  made  also  to  evolve  and  follow  the 
unavoidable  change  in  geography,  in  the  character  of  the  enemy  and  the 
threat  that  he  presents.  There  will  always  be  changes  in  doctrine, 
weapon  characteristics  and,  most  importantly  in  the  Commander's  style. 
Put  Another  way,  DOO  procurement  procedures  in  this  area  must  not  be 
oased  on  the  incorrect  assumption  that  the  software  package  nas  the 
peculiar  characteristics  of  immutability  that  one  would 
characteristically  give  to  a  radar,  a  weapon  system,  a  gun  or  a  shell. 
If  one  were  trying  to  find  a  hardware  analogue  to  software,  a  display 
comes  to  mind.  A  display  does  change  depending  upon  the  user,  upon 
strategy  and  upon  doctrine.  It  is  the  responsibility  of  DOD  and 
Industry  to  understand  in  the  case  of  software,  more  than  any  other 
form,  how  the  user  or  users  influence  the  (software)  program  and  that 
is  how  evolution  comes  about. 

following  the  discussions  of  yesterday.  Industry  is  hereby 
offered  to  continual ly  come  forward,  and  tell  those  in  DOD  and  OSD  now 
they  can  do  better,  and  how  they  can  evolve  at  a  faster  pace  to  get  to 
more  satisfactory  solutions  in  the  sense  of  our  operational  weapon 
systems.  In  this  conference,  there  is  visible  a  better  interaction 
between  Industry  and  DOD  and  the  Congress.  It  can  be  seen  how  to  work 
together  better  in  the  future.  As  an  example,  the  recently  completed 
CODSIA  report  shows  how  all  parties  can  work  together  in  the  future  so 
that  at  the  end  of  this  decade  there  will  be  solutions  the  very 
serious  problems  of  the  last  several  years. 

Answers  to  questions,  comments  and  responses  brought  out  the  following 
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Software  should  not  pre-empt  the  commander  in  the  sense  that 
his  style  should  not  be  pre-ordained  by  the  software.  The 
STARS  program  has  adaptability  in  its  title.  A  case  in  point 
is  modification  of  British  software  enroute  to  the 
Falkland  Islands  which  resulted  in  crucial  contributions 
to  the  British  success. 

Technology  time  is  very  short  compared  to  configuration  change 
and  related  management  times,  it  takes  years,  literally,  to 
get  solutions  to  software  problems  into  the  field.  It  is  not 
as  much  technology  as  management  systems  of  technology  that 
is  needed  to  bring  about  changes  in  the  field.  Changes  to  air¬ 
planes  get  into  the  field  four  years  later  and  yet  the  software 
changes.  There  needs  to  be  in  parallel  with  STARS  etc  a  look  at 
the  management  structure  of  programs  to  permit  making  changes 
in  a  reasonable  period  of  time. 

The  foregoing  comment  applies  to  more  than  software  and  is  an 
endemic  problem  across  the  whole  000.  U.S.  has  superior  tech¬ 
nology  vis-a-vis  other  countries  but  the  same  cannot  be  said 
of  embedded  technology.  The  problem  has  to  be  thought  of  in 
two  regimes.  The  first  is  that  the  weapons  system  plan  going 

into  OSARC  ZERO  must  have  provisions  for  these  problems.  The 
second  is  that  Preplanned  Product  Improvement  becomes  more  important 
downstream.  Ways  to  insert  new  technology  (promptly)  must  oe 
found.  We  should  not  wait  for  the  last  b%  of  the  solution 


it  will  cost  more.  If  insertion  is  planned  over  time  we  will 
make  progress. 

Returning  to  the  guest  ion  of  the  style  of  the  Commander  and 
adaptability  to  it,  it  is  not  clear  that  Ada  or  STARS  or  SEI 
is  really  addressing  it  but  may  have  capabilities  to  provide 
for  it.  It  is  also  not  clear  that  there  is  any  program  which 
identifies  that  reguirement  or  specifies  what  "s^vle"  is.  In 
response,  it  was  pointed  out  that  in  stratigic  l  there  is  a  set 
line  of  National  Command  Authority  from  the  President  on  down,  it 
is^necessari ly  stylized  and  the  process  is  clear.  In  tactical 
(C  )  systems  there  are  different  geographies,  different  areas, 
different  threats.  It  is  important,  and  must  be  appreciated 
that  when  the  Commander  comes  in  he  will  have  his  own  way  of 
doing  things  and  how  he  will  plan  through  to  conduct  his  area 
of  responsibility.  Ihis  must  be  taken  into  account  and  C3  is 
the  area  in  which  it  applies. 

Doctrine  can  be  too  rigid  -  so  rigid  that  if  it  is  not  effective 
alternates  which  are  effective  may  have  to  be  employed.  So 
rigid  that  corrections  to  doctrine  and  its  implementation  cannot 
be  put  in  place  effectively.  A  number  of  scenarios  for  high 
technology  would  appear  to  make  us  scenario  dependent  and  we 
become  locked  into  an  employment  scheme  that  denies  us  the 
potential  of  (a  particular)  weapon  system. 

Given  that  gallium  arsenide  offers  similar  powers  to  CMOS 


and  silicon,  and  perhaps  better  throughput,  its  import  to  DOD  is 
such  that  the  program  is  being  pushed  in  DARPA  with  very,  very 
high  priority.  There  are  some  very  important  aspects  to  it  in 
radiation  hardness.  Focal  points  are  DARPA  which  provides  seed 
money,  initiative  and  (authority)  to  proceed  with  new  tech¬ 
nology  without  requirements,  and  the  Services. 

...  Preplanned  Product  Improvement  and  technology  insertion  have 
been  discussed  for  future  systems.  Given  the  tremendous  in¬ 
vestment  in  strategic  and  tactical  systems  (now  in  inventory) 
the  question  of  streamlining  improvements  in  hardware  and 
software  in  a  kind  of  conventional  product  insertion  in  these 
systems  in  of  interest.  This  process  appears  to  take  from  5  to 
7  years  from  future  requirements  to  arrival  in  the  field  and 
(comparatively)  is  shorter  than  the  12  to  15  year  cycle  for 
new  developments. 

...  The  above  point  is  well  taken.  It  is  much  easier  for  Preplanned 
Product  Improvement  if  the  system  is  designed  to  make  changes 
with  subsystem  components  without  tearing  the  vehicle  apart. 

963  is  an  obvious  example.  In  the  main  emphasis  is  to  make  sure 
that  the  system  specifies  when  they  come  to  DSARC  will  permit 
asking  that  kind  of  question  -  looking  downstream.  Regarding 
current  systems  it  is  more  difficult  but  an  area  where  money 
can  be  saved.  The  vehicle  is  not  the  gut  of  the  system,  but 
the  weapon  system  that  is  on  it.  At  the  same  time,  there  is 
the  tendency  within  DOD  that  if  there  is  money  for  the  vehicle 
today  and  it  is  bought,  then  downstream  money  will  be  found  for  the 
ammunition  or  the  smart  system.  The  tendency  is  being  fought. 

The  OSO  approach  is  to  focus  more  on  the  "smartness"  of  the  sys¬ 
tem  and  make  the  platform  last  longer.  Congress  and  Industry 
work  together  and  put  that  kind  of  "pressure"  on  the  "system". 

The  participation  of  Israeli  scientists  in  military  assignments 
and  the  quick  turn  around  to  meet  very  near  form  requirements, 
rather  than  to  5  to  8  to  10  years  downstream  requirements  is  of 
interest.  The  whole  problem  (of  updating)  is  tough  especially 
when  budgets  go  down. 

...  Related  to  the  above  issue  is  that  one  of  the  first  and  most 
efficient  uses  of  CAD/CAM  and  Robotics  will  be  small  lot  manu¬ 
facturing  of  spares,  ability  to  get  data  packages,  and  make 
adaptations  in  the  future  in  existing  systems.  A  number  of  CAD/ 

CAM  and  Robotics  issues  focus  squarely  on  inventory  and  ability 
to  deliver  new  designs  and  high  technology  portions  into  in¬ 
stalled  systems  much  more  rapidly. 

hr .  Sumny 

This  is  a  perspective  on  the  Congress/Mi  1 itary/ Industry 
partnership  from  the  vantage  point  of  an  official  in  the  Semiconductor 
Research  Corporation  (SRC).  It  is  one  of  two  cooperative  industry 
programs  attempting  to  deal  with  the  competition  coming  from  our 
allies.  The  other  is  Microelectronics  and  Computer  Technology 
Corporat i on  ( MCC ) . 
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SRC  -  with  a  connotation  on  this  sliae  of-  both  cooperation  and 
corporation  -  wanted  to  incorporate  as  a  cooperative  but  there  were 
obstacles.  So  SRC  is  incorporated  as  a  corporation  engaged  in 
cooperative  research. 

SRC  is  a  not-for-prof- i t  corporation  that  was  established  by  the 
semiconductor  and  eletronic  systems  industry  in  this  country  because 
of  recognition  of  neglect  in  many  respects  of  a  significant  long  term 
research  program  which  would  provide  for  improving  the  competitive 
position  of  the  industry  in  the  world  market.  The  b4K  bit  RAM  was 
perhaps  the  thing  that  brought  the  problem  to  the  surface  and  caused 
the  industry  to  seriously  examine  where  is  was  and  what  its  problems 
were.  Traditionally,  in  the  past,  the  industry,  because  of  profit 
problems,  focused  on  tomorrow's  rather  than  next  week's  or  next  year's 
problems.  It  had  gotten  into  a  position  where  the  direction  of  long 
term  research  in  the  industry  needed  additional  attention.  The 
industry  put  together  the  SRC  and  it  was  chartered  to  begin  one, 
without  government  involvement  and  two,  to  start  in  the.  university 
community  so  that  perhaps  two  problems  could  be  solved  at  the  same 
time.  It  was  recognized  that  the  education  of  the  engineers  that  the 
industry  needed  was  increasingly  becoming  more  multidisciplinary. 
Perhaps  SRC  could  play  a  role  in  making  the  education  of  these 
engineers  more  relevant,  while  at  the  same  time,  defining  and 
executing  a  focused  yet  generic  research  program  supportive  of  the 
needs  of  the  industry.  That  was  the  original  charter  and  SCR  is  up 
and  running  at  this  time.  SRC  has  been  in  existence  about  18  months 
and  currently  has  about  fib  million  worth  of  contracts  in  the 
university  community  that  focus  on  eight  major  thrusts  imoortant  to 
the  semiconductor  industry.  SRC  is  looking  at  what  might  be  done  in 
the  longer  range. 
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Itonds  and  Context 


\ 


•  The  previous  separate  domains  of  materials;  devices,  circuits, 
architecture,  algorithms,  and  software  for  digital  systems  are  rapidly 
merging  into  an  Interdisdplinary'lnformation Technology' continuum. 

•  The  country  is  beginning  to  recognize 'Information Technology’as  a 
cornerstone  of  the  economy. 

•  The  Department  of  Defense  is  beginning  to  recognize ‘Information 
Technology'as  a  cornerstone  of  the  future  defense  of  the  United  States. 

•  The  equipment  to  do  meaningful  research  and  development  in  this  field 
is  becoming  increasingly  expensive. 

•  Because  of  the  importance  and  the  expense,  cooperation  between  the 
government,  industry  and  academia  is  necessary  if  we  are  to  compete 
effectively  in  the  world  economy. 


J 


All  of  the  trends  and  context  on  this  slide  are  known.  As  the 
semiconductor  industry  matures,  its  products  Decome  systems  on  a  chip 
rather  than  integrated  circuits  on  a  cmp.  With  interdisciplinary 
information  technology  in  mind  and  recognizing  its  rising  research  and 
(almost)  prohibitive  equipment  costs  as  well  as  its  importance  to  the 
national  economy,  cooperation  between  government,  industry  and 
academia  is  obvious.  We  must  explore  alternatives  to  strengthen  t.ne 
link  between  them.  That  is  the  major  point  of  this  presentation. 


Information  Tachnotogy 


^  ^ —  J  ■ 

Ihe  flow  of  information  technology  is  shown  on  this  side,  lhe 
status  and  trends  of  industry  are  shown  on  the  next  slide. 
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STATUS  AND  TRENDS  OF  THE  INDUSTRY 


•  Merchants  - 

•  Vertical  Integration  - 

•  Japanese  — 


Capital  shortages 


Increasing  trend  toward 
Market  penetration  in  key  and 


targeted  areas 


•  European 


Stagnant  but  expanding 


cooperative  efforts 


The  merchant  manufacturers  of  intregrated  circuits  in  this 
country,  as  compared  to  the  Japanese  (who  are  not  really  merchant 
manufacturers)  are  short  of  capital  because  of  the  profit  margins 
associated  with  selling  integrated  circuits. 

In  Japan,  semiconductors  are  sold  by  vertically  integrated  firms 
that  make  their  profit  primarily  (and  with  some  simplification)  from 
the  sale  of  systems.  In  integrated  circuits  they  do  not  have  to 
recoup  the  cost  of  the  increasingly  expensive  design  associated  with 
them. 

The  "PROBLEM"  is  shown  on  this  slide. 


THE  “PROBLEM” 


•  Increasing  difficulty  of  U.S.  merchant  houses  to  compete 

—  Trend  toward  U.S.  market  dominance  by  world 
competition 

—  Major  costs  of  new/future  architectures,  e.g.: 

•  $40M  —  IAPX  432 

•  $100M  —  1  mega-transistor  custom  design 

—  Projected  high  costs  of  manufacturing  facilities 
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The  trend  is  toward  domination  of  the  U.S.  market  by  other 
countries.  Examples  indicate  the  cost  of  new  and  future 
architectures.  There  is  little  or  no  room  for  mistakes  in  the  climate 
of  these  kinds  of  design  costs.  Projected  costs  for  facilities  are  in 
the  $  1 UOM  range  by  the  end  of  this  decade. 

The  next  slide  addresses  the  U.S.  strength  in  facing  this 
problem. 


The  ultimate  strength  of  our  defense 
is  the  strength  and  capability  of 
our  industry  and  the  strength  and 
will  of  our  people. 


Emphasis  will  be  placed  on  the  strength  and  capability  of  our 
(semiconductor)  industry. 

The  VHSIC  program  addressed  certain  key  aspects  from  the  military 
point  of  view  from  the  beginning.  borne  needs  not  included  in  the 
VHSIC  program  are  shown  on  the  next  si ide. 


NEEDS  OF  THE  DoD  NOT  MET  BY  VHSIC 

•  Research 

—  Silicon,  materials,  processes,  devices 
—  Manufacturing 

-  Design 

-  Systems -Beyond  silicon 

•  Faculty 

•  Students 

•  Generic  development  for  commercial  industry 

-  CAD 

-  Architecture 

-  Packaging 

-  Software 

-  Devices 

•  Stable,  profitable  items  to  generate  capital  to  plow 
back  Into  research 

•  Generic  research  and  development  support  from  the 
users  to  keep  generating  new  commercial  products 

•  Advanced  VLSI  process  across  the  industry 
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They  include  major  research  initiatives  in  silicon  and  various 
materials,  in  processes  and  devices,  research  into  manufacturing, 
research  into  design  systems  and,  particularly  into  those  system 
looking  beyond  silicon.  It  does  not  address  the  problems  associated 
with  university  faculty  or  the  training  of  students.  It  specifically 
avoids  generic  development  for  the  commercial  industry.  It  was 
established  to  meet  the  military  needs  in  the  integrataed  circuit 
arena.  So,  such  things  as  CAO,  architecture,  packaging,  software  and 
devices,  as  viewed  from  the  generic  standpoint  of  the  industry  are  not 
addressed.  VHSIC  does  not  address  R  &  D  along  the  line  of  products 
that  are  stable  and  sell  in  high  quantity  such  as  memory,  for 
instance.  (These  are)  things  it  almost  totally  avoids.  The  generic 
research  and  development  from  users  to  generate  new  commercial 
products  in  something  it  does  not  address.  The  establishment  of  a 
generic  long  term  process  that  is  product  independent  is  something  the 
industry  desperately  needs.  Again,  it  is  something  VHS1C  does  not 
address.  These  are  not  shortcomings  of  the  VHSIC  program  which 
obviously  has  its  objectives.  These  are  things  that  the  industry 
views  as  essential  that  VHSIC  does  not  address. 

What  the  semiconductor  industry  has  done  toward  solving  some  of 
the  problems  it  sees  are  shown  on  the  next  slide. 


WHAT  HAS  THE  SEMICONDUCTOR 
INDUSTRY  DONE? 


•  Formed  SRC  to  support  generic  research,  faculty, 
and  students 

•  Formed  MCC  to  do  generic  computer 
technology  development 

•  Lobbied  Government  and  Congress  for 
—  R&D  tax  credits 

—  Reciprocal  access  to  foreign  markets 
—  Capital  funding  relief 

Support  of  present  and  new  faculty  and  students  is  especially 
important.  MCC  is  a  for-profit  corporation  to  do  generiac  computer 
research.  It  consists  of  many  of  the  same  houses  as  SRC-systems 
houses,  military  houses  etc.  Some  semiconductor  houses  are  looking  at 
MCC. 

SRC  strategy  for  the  future  is  shown  on  this  slide.  Expansion  of 
research  in  the  university  community  may  research  $2U-$25  million 
from  our  member  companies  who  now  number  nearly  31).  lhey  range  from 
major  systems  houses  such  as  IBM,  COC  and  Honeywell  to  many 
semiconductor  houses  such  as  Motorola,  Intel,  National  Semiconductor, 
to  A&O  houses  such  as  General  Electric,  Westinghouse,  E-Systems, 
Goodyear  Aerospace,  to  equipment  houses  such  as  Eaton  and  to  chemi- 
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SRC  Strategy  tor  the  Future 

•  Expand  Contract  Research 
—Centers 

—Thrusts 

—Elements 

•  Expand  Research  Base 

•  Expand  Education  Activities 

•  Increase  Emphasis  on  "Systems/Components  Interaction  Thrust" 

•  Add  Research  Thrusts  •  Add  Development  Thrusts 

—Software  Research  *  —Memory 

—System  Science  —Array  Processors 

-Etc.  -Eta 

•  Discuss  Establishment  of  Generic  Research  and  Development 
Facility 


v. 
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cal  companies  such  as  Union  Carbide  etc.  They  are  a  broad  spectrum 
of  companies  that  recognize  the  problem  and  have  signed  up  on  the 
dotted  line  to  help  solve  it.  SRC  would  like  to  expand  the  research 
base  beyond  silicon  to  gallium  arsenide.  SRC  wishes  to  expand 
research  in  architecture  because  many  of  the  payoffs  to  the 
semiconductor  industry  in  terms  of  reduced  costs  will  come  through  the 
design  and  architecture  route  rather  than  materials  and  devices.  The 
key  is  the  establishment  of  a  generic  Research  and  Development 
Facility  that  will  carry  research  results  on  step  further  for  this 
industry  -  always  in  a  generic  sense. 

SRC  goals  as  shown  on  the  accompanying  slide  are 


SRC  GOALS 


•  1000  Graduate  students  supported 

•  300  Faculty  supported  '  iso 


>100  million  per  year  budget  including  facilities  and 
Jevelopment  under  discussion 


National 


Industry  . 
University 
Government 


Research  facility 


Integrate  the  information  technology  research  domain 

Help  the  U.SA  to  dominate  the  world  of  information 
technology 


1000  graduate  students  supported  of  which  are  there  350,  300  faculty 
supported  of  which  there  are  150  and  a  National  Research  Facility 
involving  Industry,  Universities  and  the  Government. 

Research  Development  and  Production  status  as  shown  on  the  next 
slide  compares  U.S.  and  Japanese  processes. 

Research  Development  and  Production  Status 


INFORMATION 

TECHNOLOGY 

USA 

INDUSTRIAL 

BASE 


MITI 


•VLSI 

•  5TH  GENERATION 

•  ROBOTICS 

8  COMPANIES 
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A  major  problem  for  the  U.S.  is  transferring  Its  major  research  and 
development  thrusts  Into  the  Industrial  base.  Japan  has  found  ways  to 
address  that  problem  for  their  country  (which  may  not  be  satisfactory 
for  the  U.S.).  They  have  shown  an  efficiency  in  going  from  research 
to  the  semiconductor  arena  of  8  major  companies  using  M1T1,  VLSI,  5th 
Generation  and  Robotics  with  the  cooperation  of  the  8  companies. 


RtwswiiDmloprMfllwid  Production  Status 


USA 

RESEARCH 
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As  depicted  on  this  slide,  SRC  liked  to  think  there  is  some  way  that, 
by  recognizing  what  VHSIC  and  SRC  are  and  their  goals  are,  the 
government,  industry  and  academia  can  be  brought  together  to  help  the 
U.S.  transition,  in  a  more  efficient  and  effective  manner,  from 
research  to  the  industrial  base. 
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The  accompanying  slide  shows  comparative  DOD  and  SRC  schedules, 
1983-87,  with  VSH1C  and  its  several  components  up  to  0.6  micron 
technology  in  the  87  time  frame.  It  also  shows  SRC  with  all  its 
components  coming  to  0.1  Micron  ill  — V  and  16  megabit  RAM  in  the  1987 
time  frame.  Hopefully  the  two  can  be  synergistic  resulting  in 
leapfrog  technology  advances  for  the  U.S.  in  semiconductor 
electronics. 


CANDIDATE  “LEAPFROG” 

DEVELOPMENT  PROGRAM 

•  05-micron  lithography  ^ 

•  Automated  manufacture  ^ 

•  Automated  CAD  l- 

•  Flexible 

•  Variety  of  device  demonstrations 

Future 

•  Wafer  scale  integration  ' 

•  Integrated  CAD— CAM— CAT  / 

•  Maskless  lithography  t. 

The  elements  of  a  candidate  leap  frog  proqram  are  shown  on  this 
last  slide.  All  of  these  program  elements  would  emphasize  generic 
research  and  resulting  flexible  capability. 

In  summing  up  it  is  emphasized  that  many  of  the  leaders  in  the 
semiconductor  industry  played  major  roles  in  formulating  underlying 
thoughts  and  concepts  in  this  (SRC)  program.  They  are  most  interested 
in  what  role  the  government  might  play  in  it.  They  feel  the  time  is 
ripe  to  gain  industry  participation  in  SRC  and  are  interested  in  what 
role  the  government  might  play.  They  would  like  to  see  the  government 
participate  with  both  finances  and  spirit.  Thus  the  impact  of 
cooperation  could  be  increased.  The  recent  SRC  Workshop  on  gallium 
arsenide,  in  which  the  government  participated,  is  an  example.  The 
result  was  a  research  program  starting  at  $500-600K  and  growing  to 
$1.5M  per  years.  SRC  would  like  to  have  government  participation  in 
further  plans  and  actions  so  as  to  include  their  needs  and  avoid 
undesirable  and  non-productive  duplication. 

The  following  points  were  made  in  answers  to  questions,  comments  and 
responses : 

...  Concerning  what  000  programs  are  doing  to  increase  awareness  at 
the  Air  Force  Institute  and  Naval  Post  Graduate  School,  VHSIC 
worked  fairly  closely  with  Naval  PG  School  where  some  programs 
tied  in  nicely  with  VHSIC  program.  To  date,  SRC  has  not  put 
together  programs  in  either  school  although  they  are  in  talk 
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and  under  consideration. 


Considerable  attention  is  being  paid  to  the  possibility  of 
DOD  providing  added  effort  in  graduate  cirricula  which  might 
not  be  research  programs  and  particularly  in  the  service 
schools.  Curriculum  revisions  are  key  in  this  effort.  Visits 
by  professors  to  service  laboratories  has  been  beneficial. 

There  is  no  formal  relationship  between  SRC  and  MCC  concerning 
CAD.  Informal  coordination  is  provided  by  persons  who  are 
directors  of  both  to  assure  cooperation  and  avoid  competition. 

Formal  ways  of  getting  together  will  be  discussed  in  board 
meetings  in  the  next  six  to  nine  months.  An  almost  identical 
set  of  companies  support  both  and  they  want  to  see  their  money 
is  spent  efficiently.  There  is  informal  cooperation. 

SRC  is  a  little  different  from  MCC  in  that  research  it  funds 
in  universities  is  not  restricted  to  member  companies.  DOD 
is  finding  it  difficult  to  become  involved  because  of  the 
totally  free  publication  policy  of  SRC  which  inhibits  DOD 
from  becoming  a  paying  member.  SRC  is  aiming  for  middle 
ground  where  government  can  become  involved. 

Concerning  implication  that  there  would  be  a  National  Research 
Facility  in  integrated  circuits,  it  was  stated  it  would  be  an 
outgrowth  of  generic  research  programs.  Sites  have  been  studied 
and  SRC  would  like  government  to  participate  so  it  can  re¬ 
spond  to  government  as  well  as  industry  needs. 

SRC  seems  to  have  recharacterized  the  university,  to  have  moved 
away  from  the  basic  research  kind  of  information  development 
that  is  protected  by  the  Constitution  as  private  information 
and  therefore  not  subject  to  prior  review  and  constraints.  At 
the  same  time  (SRC  seems  to  have  moved)  into  the  area  of  uni¬ 
versities  doing  a  lot  more  applied  development  and  what  would 
be  considered  as  commercial  technology.  This  introduces  all 
kinds  of  questions  of  rights  and  prior  review  and  screening  of 
papers  whether  it  be  for  export  control,  patent  policy,  secrecy 
checks,  etc.  We  have  opened  up  a  whole  area  for  .dispute  resolu¬ 
tion  are  not  prepared  to  deal  with  or  haven't  shown  a  lot  of 
strength  in  dealing  with.  This  is  not  only  in  the  semiconductor 
area  but  also  in  biology,  genetic  engineering  and  pharmaceutical 
areas.  There  is  a  question  how  generic  SRC  programs  really  are 
and  whether  we  can  stop  having  all  kinds  of  mechanisms  in  the 
university  that  restrict  the  free  flow  of  scientific  information 
and  set  up  a  whole  new  culture. 

Response  to  this  comment  indicated  that  apart  from  possible  se¬ 
mantic  problems,  SRC  is  not  funding  development  in  the  universi¬ 
ties  but  is  funding  basic,  and  hopefully  more  basic,  research.  Basic 
research  does  not  have  to  be  totally  undirected  or  non-focused. 

SRC  has  a  standard  contract  that  has  been  negotiated  with  over 
35  schools  that  seems  to  be  acceptable  to  all  of  them  over  this 
short  period  of  time.  Since  there  aren't  real ly  major  amounts  of 
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money  involved  it  is  because  both  sides  see  the  advantage  of 
\  jointly  addressing  the  problem.  SRC  encourages  schools  to 
apply  for  patents.  SRC  allows  for  open  publication  after  an 
opportunity  to  review  articles  to  see  if  there  are  patentable 
ideas  that  the  universities  perhaps  have  missed.  Our  member 
companies  enjoy  non-exclusive  royalty.  Free  yse  of  patents  that 
might  ensue  from  SRC  research  programs  many  of  the  foregoing 
problems  are  being  addresses  and  approaches  to  them  will  be 
refined  as  we  move  forward.  To  date  there  has  not  been  any 
fundamental  problem  on  either  side. 

...  There  is  great  difficulty  in  taking  a  product  from  development 
(such  as  National  R  &  D  Faculty)  into  production,  moving  it 
from  a  partner  to  another  and  distributing  it  to  5  to  20  com¬ 
panies  and  have  them  all  be  able  to  accurately  produce  the  pro¬ 
duct.  SRC  recognizes  it  as  a  fundamental  important  problem  is  not 
sure  they  have  the  answer  and  is  making  a  series  of  visits  to 
interested  companies  over  the  next  three  weeks.  It  is  funda¬ 
mental  to  success  of  anything  SRC  may  do  in  this  area.  The 
thinking  is  that  once  the  process  is  understood  in  a  scientific 
way,  in-process  monitoring  can  be  provided  for  and  sensors 
developed  to  know  what  is  going  on  in  the  process  (rather  than 
just  input  and  output)  and  there  will  be  better  ability  to  trans¬ 
fer  technologies.  Most  companies  are  totally  unsuccessful  in 
developing  in  one  place  and  transferring  to  another  line.  The 
ability  to  do  that  is  crucial  to  SRC  approach. 

...  Referring  to  the  "1000  student  and  J00  faculty"  goal,  and  the 
current  crisis  in  education,  if  students  are  not  put  into  the 
pipeline  at  the  high  school  level,  there  will  not  be  enough 
students  in  the  pipeline  to  meet  national  needs.  SRC  is  not 
sure  how  to  address  that  problem.  One  SRC  goal  is  "to  expand 
education"  and  high  school  input  is  included  in  that  goal.  Many 
of  the  companies  are  addressing  it  on  their  own  in  various  ways, 
although  not  always  coordinated  with  what  SRC  would  like  to  do. 

It  is  under  discussion  and  SRC  is  looking  at  it. 

Mr.  Cittadino 

This  speaker  was  introduced  by  Or.  Lyon  who  emphasized  that  there 
are  two  distinct  areas  in  D00  requirements  in  the  year  2000.  The 
first  is  the  tremendous  amount,  of  internal  communication  and 
interfacing  with  computers  and  software  becoming  almost  the 
determinant  of  system  performance.  The  second  is  vulnerability 
between  systems  and  the  dependency  on  communications  between 
cooperative  functional  subsystems  which  can  not  be  co- located.  • 

|his  presentation  covers  how  computers  and  software  fit  into 
the  C  world,  what  the  problems  are,  some  things  being  done  in  DOO 
and  some  observations  on  ^hat  000,  Congress  and  industry  can  do  to 
help  (Theater  laactical  C3  Directorate)  get  its  job  done.  Theater  and 
Tactical  CJ  will  be  emphasized  but  many  observations  I  1  also  apply 
to  tactical  intelligence,  strategic  systems,  counter  C3  and  the  like. 
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There  is  an  awful  lot  of  equipment  and  systems  out  in  the 
battlefield  and  it  is  all,  in  the  future,  going  to  be  data  oriented. 
Lines  for  data  exchange  between  computers  will  be  required.  It  is  a 
big  job  to  make  sure  they  can  be  tied  together.  There  are  DOD 
programs  aimed  at  precisely  that  requirement.  Secretary  Weinberger 
will  shortly  sign  the  establishment  of  a  new^agency  called  Joint 
Tactical  C;  Agency.  Its  main  role  will  be  C  systems  integration  and 
interoperabi 1 ity. 

3 

1  act i cal  C  systems  have  to  live  in  a  tough  environment. 
Survivability,  both  physical  and  in  an  ECh  environment,  is  very 
important.  Affordability  is  a  very  big  issue.  As  an  example,  JTIDS 
will  provide  information  exchange  between  tactical  computers  in  a  Navy 
environment  of  air,  surface  and  subsurface  warfare  simultaneously. 

The  need  is  shown  on  this  chart. 


THE  NEED 


•  MOVE  DATA 

•  PROCESS  DATA 

•  DISSEMINATE  DECISIONS 

Ihe  computer  is  central  from  main  frames  in  fixed  locations  right 
down  to  microrpocessors  in  man-packs  for  navigation  and  digital  voice 
communications. 


The  job  of  DOO  and  industry  is  to  get  embedded  computers  out  to 
the  troops  that  need  them.  It  is  worth  looking  at  what  the  job  is  and 
how  we  have  been  doing  it.  lo  an  outside  observer  the  solution  should 
be  simple. 


THE  SOLUTION  SHOULD 
BE  SIMPLE! 


•  POLICY 

•  MONEY 


•  EXCESS  TECHNOLOGICAL 
CAPACITY 

It  is  policy  in  the  Carter  and  Reagan  administrations  that  C°  is 
a  very  important  high  priority.  President  Reagan  in  his  Defense 
package  named  C3  as  the  highest  priority  within  our  strategic  * 
defenses.  OASD/DOD  officials  have  led  the  fight  to  insure  that  C3  is 
treated  with  equivalent  priority  and  resource  allocation  to  the  weapon 
systems,  that  C3  does  not  get  swept  aside  dv  the  services  in  the 
desire  to  get  more  weapon  platforms  into  the  field,  and  that  there  is 
a  balance  there.  If  C3  budgets  are  examined,  it  can  be  argued  that  a 
lot  of  money  is  not  being  spent  on  them.  The  technology  we  have  far 
surpasses  anything  in  th<=  world  and,  in  the  view  of  some  we  have  more 
than  we  need  to  do  the  CJ  job. 

FY  84  ALLOCATION  OF  RESOURCES 


DOD  BUDGET 
$274B 


C3  I  BUDGET 
$16.7B 


There  was  $16.76  In  the  1984  Budget  which  was  out  roughly  4%  by 
Congress.  Intelligence  money  is  roughly  the  same  ballpark  as  C  .  Of 
the  C  money  there  is  $6B  for  theater  tactical  CJ  and 
naviqat ion/warfare  C  . 

TECHNOLOGY  FOR  C3  SYSTEMS 


COMPUTER  HARDWARE/SOFTWARE  TECHNOLOGY  HAS 
EXCEEDED  OUR  ABILITY  TO  APPLY  IT 


As  depicted  on  this  slide  we  have  reached  the  point  where 
technology  is  not  the  issue.  We  have  exceeded  the  requirement  for 
technology  capability  to  satisfy  our  needs.  OSO/DOO  is  looking  at 
other  solutions  than  just  advancing  the  state  of-  the  art.  In  isolated 
cases,  this  is  not,  so  such  as  VHS1C  tor  processing  we  need  in  certain 
radar  systems,  and  gettinq  anti-jam  communications  down  to  smaller 
sizes.  By  and  large  we  think  we  have  more  technology  than  we  really 
need. 


WE  HAVE 
MISSED  THE 
MARK! 


\ 


10  TO  15  YEAR 
DEVELOPMENT  CYCLE 
IS  NOT  GOOD  ENOUGH 


-85- 


So  we  are  at  the  point  where  we  have,  ana  continue  to,  miss  the 
mark  and  where  the  10  to  IS  year  development  cycle  is  just  killing  us.  We 
should  take  a  lesson  from  the  Israelis.  When  the  war  starts,  from  all 
military  authorities  it  is  going  to  be  a  short  war.  If  it  is  an  all 
out  conventional  war  in  Europe,  It  Is  going  to  be  a  come-as-you-are 
war.  There  Is  serious  concern  that  we  are  not  as  prepared  for  that 
war  as  we  should  be. 

Why  do  we  have  this  problem?  Change  is  the  problem  we  have  to 
contend  with.  If  you  are  familiar  with  the  environment  in  which 
operates,  every  element  of  it  is  in  a  constant  state  of  flux. 


THE  ENVIRONMENT 
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The  threat  is  changing,  doctrine  changes  to  meet  the  threat,  this 
changes  the  needs  of  decision  makers  and  the  types  of  decisions  they 
have  to  make.  That,  in  turn,  feeds  back,  changes  command  and  control 
architecture,  technology  shows  better  ways  to  do  things  which  in  turn 
iterates  back  into  the  architecture.  Within  all  of  this  we  have  to 
allow  the  flexibility  to  send  our  systems  to  different  parts  of  the 
world  to  be  used  by  different  commanders.  We  have  to  design  our 
systems  to  handle  the  change  that  is  inevitable.  In  addition  to  the 
change  in  the  cycle,  there  are  the  basic  political  problems  in  keepinq 
programs  stable.  Congress  plays  a  role  in  this  in  their  funding  of 
programs  and  this  has  a  tendency  to  create  a  lack  of  stability.  DOD 
plavs  a  role  in  that  they  constantly  review  programs  looking  for  the 
Detter  mousetrap  that  industry  tells  them  is  coming  down  the  pike. 

There  are  some  things  DUO  is  doing  to  promote  stability  and 
accelerate  the  acquisition  cycle.  In  the  L  world  OSD^OOD  has  been 
using  its  version  of  Preplanned  Product  Improvement  (P3)).  Recent 
AfCtA  and  NS  I A  reports  give  good  explanations  of  P31  process  and 
rationales  for  improving  the  cycle.  P3I  had  its  genesis  in  19/8  when 
the  Defense  Science  Board  Task  force  concluded  that  IT  systems  were 
indeed  different  from  weapon  systems  from  the  development  point  of 
view.  There  is  heavy  man-macnine  interaction  and  flexibility  to 
provide  for  different  commanders  (needs)  to  oo  the  job.  Ihey  are 
cheaper  to  build  in  development.  I  here  is  the  opportunity  to  use 
off-the-shelf  equipment  to  put  systems  together  and  this  is  hard  to  do 
with  a  tank  or  an  airplane. 

TO  COMBAT  CHANGING  ENVIRONMENT 
WE  CHOOSE  TO  USE  EXCESS  CAPACITY 


•  EVOLUTIONARY  ACQUISITION 

•  NON-DEVELOPMENT  ITEMS  APPROACH 

•  STANDARDIZATION  OF  MILITARIZED  HARDWARE 

•  ARMY — MCF/N AVY  STANDARD  CPU 

•  MILITARIZATION  OF  COMMERCIAL  MACHINES  (NDI) 

•  HIGHER  ORDER  LANGUAGES 

•  ADA 

Basically,  Evolutionary  Acquisition  says  the  user  defines  the 
requirements  very  broadly  and  works  with  the  developer  to  provide  a 
specification  tree.  This  allows  a  system  to  put  toqether  in  a  hurry 
using  existing  hardware  -  military  goverment  owned  or  commercial 
off-the-shelf.  An  operating  system  is  put  together  and  a  minimum  set 
of  applications  software  is  provided  to  do  a  minimum  job  for  the 
commander.  I  hen  the  equipment  is  put  in  the  hands  of  an  actual  user. 
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It  is  given  to  a  user,  not  a  test  facility,  and  a  mechanism  is 
provided  for  feedback  to  the  developer  so  he  can  improve  and  "grow" 
the  system  from  a  software  point  of  view. 

Aother  thing  UOD  and  the  Army  are  doing  is  looking  at  commercial 
gear  and  systems  that  have  been  developed  off  shore,  suiting  them  to 
the  requirement  and,  if  need  be,  giving  up  on  the  requirement  in  the 
interest  of  getting  things  faster  and  cheaper. 

A  third  thing  is  the  standardization  of  militarized  hardware. 
Examples  are  the  Army  MCE  and  the  Navy  AN/UYK4i  and  44  Program.  Here 
the  thrust  is  to  see  if  it  makes  sense  to  standardize  on  a  family  of 
equipment  and  then,  in  a  given  period  of  time,  redevelop  that 
equipment.  There  may  be  changes  in  the  standardization  thrust  to  be 
consistent  with  Dr.  Martin's  presentation  yesterday. 

Next  is  the  question  of  what  to  do  about  software  which  has  been 
the  "long  pole  in  the  tent"  from  both  cost  ana  time  points  of  view. 
Here  it  is  hoped  that  the  answer  is  to  get  high  order  languages,  get 
Ada  out  into  the  field.  Then  go  through  the  long  agonizing  transition 
which  must  be  experienced  as  new  systems  and  subsystems  with  Ada  are 
introduced  and  as  previous  systems  (which  are  so  costly  to  maintain 
and  time  consuming  to  keep  modernized  in  the  field)  are  phased  out. 

It  is  hoped  Ada  is  the  "light  at  the  end  ot  tunnel"  to  help  produce 
software  quicker,  cheaper  and  more  error-free. 

A  CURRENT  BOTTLENECK  TO  SUCCESS  IN  C3 


RESOLVED 

Standardization  of  military  hardware  is  an  issue  that  is  not 
resolved.  The  question  is  whether  to  go  for  new  technology,  to  make 
more  thorough  use  of  non-developmental  items  or  to  standardize  on 
DOD/Service  developed  computers.  UOD  solicits  feedback  from  industry 
on  this  issue. 
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To  repeat,  the  two  main  thrusts  of  DOD  are  to  push  for  use  of 
higher  order  languages  as  a  policy  and  to  impress  upon  the  development 
world  of  the  Services  that  we  just  have  to  meet  requirements  quicker 
and  more  cheaply. 

"The  Better  is  the  Enemy  of  the  Good"  is  an  old  cliche  but  it 
applies  and  perhaps  should  be  emphasized.  One  of  the  problems  with 
stability  is  that  industry  is  constantly  telling  the  Services  that, 
over  the  horizon,  there  is  a  better,  cheaper,  higher  capacity,  smaller 
and  lighter  alternative.  Users  may  then  think  it  is  a  lot  neater  than 
what  is  in  development  and  that  they  should  wait  for  it.  There  are 
numerous  examples  of  systems  that  have  gone  through  Full  Scale 
Development,  been  tested,  fixes  installed  during  test  and  have  never 
been  produced  because  of  better  "over  the  horizon"  prospects.  Gls  in 
the  field  can't  wait  4  to  6  years  for  that  "better  mousetrap"  to  come 
a  I ong . 


MUST  WORK  TOGETHER 


Turning  to  a  partnership  theme  of  tnis  session  we  have  to  get 
over  the  adversarial  relationship  that  Congress,  DUD  and  Industry  have 
had  in  the  past.  It  is  improving  but  it  we  can't  get  it  to  be  a 
partnership  out  into  the  field,  we  have  not  gotten  there.  We  can  put 
a  lot  of  stuff  into  development  and  come  up  with  a  lot  of  good  ideas 
out  the  bottom  line  for  DOD  acquisition  is  getting  equipment  out  into 
the  hands  of  the  troops.  It's  not  profit  or  loss. 

DOD  can  foster  the  Evolutionary  approach,  convince  developers 
they  have  to  take  some  risk  In  building  things  quickly,  getting 
equipment  out  into  the  field  although  it  is  not  fully  tested,  set  up 
mechanisms  where  developers  are  not  antagonistic  toward  user  and 
listen  to  what  the  users  are  telling  them.  DOD  has  to  make  sure  the 
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Services  scrub  their  requirements.  The  normal  procedure  in 
establishing  requirements  is  for  the  user  to  write  down  all  the  things 
he  would  like  to  have  in  the  system.  He  is  not  worried  about  the  bill 
and  is  afraid  that,  if  any  item  is  not  in  the  requirement  he  may  never 
see  it.  Often,  when  it  comes  out  of  development  we  cannot  afford  to 
produce  the  system  or  equipment.  Scrubbinq,  in  C3  by  the  services, 
means  to  qet  all  the  bells  and  whistles  out  and  have  the  product  do 
the  basic  job  that  is  required.  000  is  pushing  on  this  -  in  essence 
everything  it  can  do  to  speed  up  the  development  cycle. 

As  OOD  sees  it,  some  of  the  things  Congress  could  do  would  be  to 
help  understand  the  need,  get  a  better  dialogue  going  (which  is 
happening),  give  direction  to  help  keep  programs  stable  and  avoid 
micro-management  and  stringent  conditions  on  programs. 

To  promote  the  partnership  Industry  can  work  closely  with  the 
government  on  the  Evolutionary  Acquisition  idea.  The  NSIA  study  holds 
that  Industry  should  be  brought  in  while  the  requirements  and 
specifications  are  being  written  so  that  industry  can  cost  the 
specification  while  the  government  is  putting  it  together.  The  NSIA 
study  was  done  for  General  Stansbury  at  ESD  so  its  thrust  is  mainly 
towards  the  Air  Force  so  far.  OSD  is  working  to  get  the  Army  and  Navy 
to  hear  the  results  and  decide  if  it  also  applies  to  them,  which  USD 
thinks  it  does.  To  re-emphasize,  pushing  the  better  mousetrap  for 
whatever  business  and  marketing  reasons  creates  a  dilemma  for  the 
government.  OSD  needs  industry  help  more  in  finding  lower  cost 
solutions  rather  than  high  technology  solutions.  OSO  has  a  tremendous 
affordability  problem  when  comparing  what  has  to  be  produced  among  all 
the  requirements  it  has.  OSD  just  does  not  have  enough  production 
do  I lars  to  do  it. 


MAKE  ONE  CHANGE  IN 
PERCEPTION 

WE  NEED: 

NOT  THE  BEST 

****** 

THE  GOOD  ENOUGH! 

BUT  WE  NEED  IT  NOW! 

In  summary,  OSD  does  not  need  the  best,  it  does  need  the  good 
enough,  but  it  needs  it  sooner  and  it  needs  to  cheaper. 

The  following  points  were  made  in  answer  to  questions,  comments 
and  responses. 
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There  is  a  dilemma  in  encouraging  industry  to  make  available 
new  technology  in  the  climate  of-  emphasizing  good  enough,  cheaper 
and  sooner  and  evolutionary  development.  There  is  no  mechanism 
for  government  looking  at  technology  while  industry  is  developing 
it  so  there  is  a  question  how  it  is  to  be  inserted.  It  appears 
that  it  can  be  done  only  over  a  period  of  time  since  there  is 
no  mechanism  for  developing  things  (for  insertion)  outside  of 
the  program  requirements. 

In  response,  the  C3  office  in  OSD  wants  it  cheaper  and  faster, 
not  better.  It  is  not  concerned  whether  we  need  better  tech¬ 
nology  which  will  come  as  industry  looks  at  each  new 
requirement.  The  problem  seems  to  be  in  management,  not  the 
horizons  of  technology.  Comparing  what  we  have  in  the  field  today 
to  what  we  were  capable  of  giving  the  military  five  years  ago, 
we  would  be  way  ahead  of  the  game.  There  does  not  seem  ro  be  a 
problem  in  the  tactical  CJ  world  to  push  technology,  it  will 
take  what  is  there.  The  problem  is  managerial  implementation 
of  systems.  There  is  the  question  of  having  the  use  of  a  less 
capable  system  over  several  years  or  no  capability  at  all  while 
waiting  for  advanced  technology.  OSD  needs  things  today.  In¬ 
dustry  can  give  technology  to  meet  a  system  need  to  go  into 
production  in  six  years  and  it  will  be  cheaper,  better  and 
lighter.  The  problem  is  that  industry  convinces  people  that  it 
makes  sense  to  stop  and  wait.  We  do  that  in  a  never  ending  cycle. 

Non-Development  Items  (NDI)  seems  to  be  a  way  to  avoid  the  real 
issue  (but)  of  how  to  get  hardware,  commercial  or  otherwise  into 
the  system.  KFPs  are  out  for  u  which  do  not  address  software 
requirements  in  a  meaningful  way  out  emphasize  NDI  hardware. 

The  real  issue  in  system  requirements  is  how  to  deal  with  the 
pervasive  threat.  This  has  nothing  to  do  with  equipment  if  the 
other  problems  are  not  solved.  000  seems  always  in  a  rush 
without  enough  front  end  inputs  and  then  goes  for  hardware. 

When  000  talks  NDI  it  is  software  and  hardware,  the  total  con¬ 
cept  of  which  is  going  into  Evolutionary  Acquisition  programs. 

If  software  is  completed.  It  fits  into  NDI  part  of  the  acquisi¬ 
tion  programs.  If  software  is  completed,  it  fits  ihto  NDI 
part  of  the  acquisition.  Examples  are  field  switching  systems. 

Concerning  DOD  willingness  to  relax  logistic  support  and  data 
rights  requirements  in  fielding  NDIs,  it  was  stated  OSD  pro¬ 
cures  very  little;  the  Services  do  the  procuring.  Relaxation 
is  encouraged  where  it  makes  sense  -  in  data  rights  it  depends 
on  application,  number  being  bought,  expected  life  etc.  Logistics 
aspects  are  being  looked  at  by  the  Services  on  a  case  by  case 
bas i s . 

Concerning  valuable  program  features  such  as  configuration 
management  and  preserving  them  in  instances  of  "budget  crunch" 
there  has  been  a  major  reorganization  in  the  CJ  world.  JTC3A 
will  become  configuration  manager.  There  is  recognition  in 
000  and  Congress  that  configuration  management  is  a  very  im- 
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portant  function.  A  recent  Congresionai  query  was  how  000 
will  handle  configuration  management  of  software  and  inter- 
operadility.  More  emphasis  and  resources  are  being  put  on 
configuration  management. 

Concerning  management  of  change,  a  reported  instance  of  initial 
design  of  a  PROM  to  accommodate  later  chanqes  possible  of 
completion  in  two  weeks  in  all  systems  in  the  field,  removal 
from  aircraft  ran  counter  to  removal  publications  and  require¬ 
ments  and  require  a  year  to  accomplish,  lhis  is  a  problem  and 
it  adversely  affects  the  moral  of  people  in  industry.  OSD  admits 
DUD  has  been  and  still  is  guilty  of  causing  problems  in  the 
management  of  change.  It  is  difficult  to  overcome  ingrained 
bureaucracy  of  customary  methods.  Specifications  and  require¬ 
ments  are  never  thrown  away.  There  are  so  many  people  over¬ 
looking  the  doers.  So  much  time  is  spent  overviewing  and 
criticizing  that  there  are  precious  few  resources  to  make  pro¬ 
gress.  It  starts  with  Congress  and  GAO  and  it  goes  down  throuqh 
UOD  where  these  guardians  of  the  regulations  have  to  fill  out 
all  this  paperwork  before  a  piece  of  equipment  can  be  taken  out 
of  an  airplane.  They  insist  that  is  tne  way  it  has  to  be  done. 

At  the  same  time  DOO  cannot  have  anarchy,  it  has  to  have  some 
disciplined  system.  At  this  time  we  are  upgrading  our  systems  and 
it  is  not  easy. 
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SUMMARY/WHAP  UP  SESSION 


Mr.  Hobeimann 

Ihe  theme  of  the  Wrap  Up  Session  was  future  capabi lities, 
perhaps  a  Cray  in  a  suitcase  in  1990,  and  impressions  of  the 
conference.  MlLCOM  III  would  not  have  been  possible  without  AUPA  and 
Col.  Bruce  Holt  and  his  crew.  The  conference  expressed  its  thanks  for 
their  help,  first,  Session  Chairmen  were  asked  for  a  summary  and 
sense  of  what  has  occurred,  from  their  associations  directly  or 
indirectly  with  the  issues  over  the  last  three  years,  and  where  we  are 
now  after  having  started  with  a  tremendously  discordant  group  at 
MlLCOM  I.  Second,  trie  floor  was  opened  for  remaining  questions  and 
comments. 

Or.  Lyon 


Session  III  on  the  evolving  partnership  -  Conqress/DOO/ I ndustrv  - 
was  structured  to  be  more  positive  about  this  issue.  Last  year  (1983) 
MlLCOM  II  started  with  high  level  policy  people.  Senator  lower 
handled  the  subject  with  no  special  notes  out  with  remarkable 
sophistication  and  knowledge  of  the  subject.  Senator  Bingaman, 
although  new  to  Congress  and  the  topic,  showed  he  is  coming  up  on  that 
curve  very  fast.  Senators  and  Congressman  do  get  information,  and 
with  their  political  backgrounds  and  sense  of  trade-offs,  piay  a 
sophisticated  ana  knowledgeable  role  in  tnis  process.  It  is  very 
important  tor  the  community  to  listen  to  them. 


The  real  issue  of  MlLCOM  II  is  that  the  growth  of  technology  is 
driven  by  factors  we  cannot  control.  Thinqs  are  going  to  happen  at  a 
rate  discussed  by  Mr.  Miller  in  his  inustry  perspective.  Ihe  question 
is  how  to  utilize  these  rapid  advances  in  defense  of  this  country  and 
provide  a  deter rant. 


Although  there  is  lessening  dissention  and  more  talking,  there  is 
still  a  need  to  communicate.  It  should  be  based  on  understanding  of 
principles,  concepts  and  assumptions  of  the  different  roles  of  the 
various  participants.  It  should  encompass  the  transfer  of  values,  it 
you  will,  across  these  various  frameworks.  Then  are  complex 
trade-offs  and  nearly  half  of  the  questions  are  “dilemma"  questions. 
Because  of  that,  there  is  no  simple  solution  except  constant  continued 
discussion.  As  things  evolve  certain  parameters  become  fixed  and  the 
variables  change. 


The  MlLCOM  series  has  started  a  process  and  it  must  be  decided 
when  it  ends.  So  this  session  will  pose  to  the  conference  whether 
MlLCOM  IV  makes  sense  and  if  so  what  should  be  done  in  it.  It  will 
come  up  in  committee  and  it  is  not  certain  what  form  MlLCOM  IV  should 
take.  Sesion  III  here  seems  to  have  accomplished  about  80%  of  its 
objectives  but  there  is  more  to  do. 


Or.  Lieblein 

Session  II  provided  a  good  coverage  of  the  spectrum  of  emerging 
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technologies.  Information  systems  and  technology  was  most  emphasized 
in  strategic  systems  and  computers.  Software  and  hardware  were 
covered. 

It  was  pointed  out  there  is  a  tremendous  momentum  in  the 
technology  and  things  will  happen  sooner  than  anticipated.  The 
technology  provides  tremendous  opportunities  and  poses  problems  of  how 
to  get  it  into  our  fielded  systems.  We  should  not  sacrifice 
capability  waiting  for  tomorrow's  technology. 

Improving  of  system  capability  through  software  is  also  a 
technology  insertion.  Mechanisms  for  inserting  technology  in  both 
software  and  hardware  is  needed.  On  the  hardware  side,  mechanisisms 
are  needed  for  insertion  of  technology  throughout  the  life  of  the 
system.  This  is  possible  in  the  computer  area  of  technology  and  in 
ways  suggested  in  the  keynote  address.  Software  insertion  was  not 
addressed  in  Session  II.  What  we  call  softrware  maintenance  is  really 
evolutionary  software  development.  We  have  institutionalized  around 
"software  maintenance"  and  in  (up  to)  very  large  systems  which  never 
have  a  stable,  rather  a  continually  evolving  requirement.  At  some 
point,  it  is  declared  "development"  is  done  and  software  is  passed  to 
a  government  support  or  maintenance  activity.  The  developing  activity 
consists  of  2U-500  software  experts.  Some  of  the  software  is  on  paper 
but  a  lot  is  in  the  experts  heads.  Although  there  are  reasons  why 
this  has  been  done,  there  are  concerns  about  lock-in  to  the  original 
contractor.  A  way  has  to  be  found  for  the  system  of  hardware  and 
software  to  evolve  together.  It  is  not  a  solution  where  we  have  the 
initial  developer,  so  long  as  he  is  able  to  do  a  good  job,  provide 
support  through  the  evolution  of  the  system.  This  problem  was  not  in 
the  studies  referred  to  above.  Management  of  change  is  a  government 
responsibi I ity. 

There  are  some  very  new  ideas  in  the  study  referred  to  in  the 
keynote  address  that  both  government  and  industry  contributors  thought 
were  good.  The  ideas  have  not  (yet)  stood  the  test  of  time  and  they 
need  work. 

We  should  look  at  a  total  computer  -  system  interface  approach 
and  see  if  industry  will  build  necessary  products  that  the  government 
can  acquire  as  off-the-shelf  or  as  NO  I  items.  We  probably  should  not 
develop  anything  we  don't  have  to  -  we  always  seem  to  have  trouble 
developings  things.  This  is  a  radical  departure  and  will  take  some 
maturing,  OSD  has  an  open  door,  would  like  feedback,  and  has  proposed 
a  framework  for  solutions.  Now,  we  have  to  work  at  it. 

OSD  is  very  serious  about  establishing  Computer  Systems  Interface 
Working  Group  (CS1WG)  and  hopes  industry  will  set  up  a  "sister"  group 
through  an  organization  such  as  CODSIA  where  all  of  the  commercial  and 
government  defense  community  are  involved.  We  would  like  to  proceed 
to  a  solution  for  the  next  generation.  We  are  going  ahead  with  the 
present  operation  and  it  is  the  right  thing  to  do.  We  nave  time,  not 
a  lot  but  enough,  to  work  out  a  good  solution.  It  is  tremendous 
opportunity  because  usually  everything  is  "crash",  because  we  can  work 
together,  because  we  don't  have  to  worry  about  vested  interests  - 
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favorite  architectures,  busses,  etc.  and  Decause  we  are  not  going  to 
be  thinking  about  what  exists  today  unless  there  is  nothing  better. 

It  is  a  "clean  slate”  situation  and  0S0  is  looking  forward  to  working 
with  the  community  on  this. 

Mr.  Grosson 

General  Hyde  presented  a  perspective  of  the  formidable  scope  of 
systems  problems  and  systems  of  the  future.  Admiral  Meyer  made  the 
central  point  that  the  job  of  DOD  is  ware  fighting  too.  After  000 ’s 
primary  mission  gets  diluted  with  social  programs,  business  management 
policies  and  adversarial  game  playing.  Adminral  Meyer  made  the 
further  point  that  everything  that  will  contribute  to  our  war  fighting 
capability  must  be  pursued.  We  should  cut  costs  to  deploy  more 
systems.  We  should  beat  schedules  in  order  to  have  more  systems 
available.  We  should  optimize  performances  to  do  the  job  particularly 
in  the  areas  of  reliability,  fault  tolerance,  survivability, 
self-heal inq  techniques  and  security.  The  bottom  line  and  the  highest 
priority  concern  should  always  be  war  fighting  capability. 

The  fol lowing  points  were  made  in  answers  to  questions,  comments  and 
responses : 

—  There  should  be  a  M1LC0M  IV  and  if  there  is  it  should  emphasize 
management  and  insertion  of  technology  dealing  with  budget  cycles 
ALCs,  configuration  control  of  hardware  and  software  and  users 
in  the  field  -  lots  of  persons  and  viewpoints.  It  is  the  biggest 
issue.  We  can  generate  more  technology  than  we  can  every  insert. 
We  are  passing  the  stage  in  computers  that  by  the  time  they  are 
in  the  field  there  are  two  more  generations.  The  management  and 
insertion  of  technology  is  really  what  DOD  should  be  concerned 
with.  It  ties  in  with  the  problem  that  we  develop  systems  that 
don't  go  into  inventory  -  valuable  resources  are  put  into  a  de¬ 
velopment  and  then  there  is  not  profit  in  the  program.  It  is  a 
major  issue  which  should  be  addressed  and  it  is  recommended  it 
be  adopted  for  MlLCOM  IV. 

...  If  technology  is  being  driven  by  forces  outside  of  DOD  -  Industry 
control  we  need  to  learn  how  to  use  it.  My  comment  is  for 
MlLCOM  IV  -  system  level  management,  new  technology  and  tech¬ 
nology  insertion  -  not  at  the  policy  level  but  down  at  the  pro¬ 
gram/project  level. 

...  borne  disagreement  with  the  foregoing  was  expressed.  There  was 
a  1976  Science  Board  Study  that  said  the  commercial  marketplace 
was  adequate  to  meet  the  needs  of  the  Defense  Department  and 
therefore  funding  for  R  &  D  in  commercial  circuits  was  not  need¬ 
ed  and  could  be  reduced.  One  year  later  we  had  VHSIC.  People 

recognized  that  the  program  manager  could  not  reach  to  that  com¬ 
mercial  marketplace  had  to  be  found  and  structured  to  put  that 
technology  within  the  reach  of  the  program  manager.  What  might 
be  called  an  "off  line  maturing  program"  was  created.  In  the 
last  year  and  a  half  ( 1 982— *33 )  a  lot  of  time  was  spent  in  look¬ 
ing  at  the  technologies  in  this  country  that  would  allow  for 
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technology  insertion  in  the  field  of  existing  systems.  It 
was  found  there  are  a  number  of  holes  where  the  spontaneous 
forces  of  the  commercial  marketplace  are  not  going  to  perform 
that  technology  and  get  it  within  the  reach  and  grasp  of  the 
programs.  It  is  a  technology  maturation  policy  problem.  Theo¬ 
retical  solutions  cannot  make  technology  get  into  the  field.  It 
is  getting  technology  formed  in  such  a  way  a  manager  can  grasp 
it  and  bring  it  into  his  program.  That  is  where  there  is  a 
policy  issue  left  to  be  resolved. 

Ihere  may  be  a  policy  guestion  but  at  the  systems  level  there 
is  a  problem  of  VHSIC  insertion.  It  is  one  of  the  major  VHS1C 
problems  -  how  that  technology  is  to  be  disseminated  among  the 
job  shops  and  managed  at  the  system  level.  This  needs  to  be 
tackled  because  it  is  not  going  very  well. 

Although  the  CODS 1 A  report  is  in  circulation  to  the  industry 
associations  who  must  accept  or  reject  it  and  has  not  yet  been 
approved  it  can  be  stated  three  segments  of  industry  -  commercial 
sector,  systems  integrators  and  specialty  houses  that  design 
things  strictly  to  MILSPEC  -  can  all  agree  in  some  areas  and 
will  never  agree  in  others.  Then  CSIWG  was  discussed  and  an 
industry  group  to  work  with  it.  There  are,  however,  four  members 
in  the  partnership  (Congress,  DOL),  Industry,  Academia).  Congress 
being  concerned  about  the  military-industrial  complex,  a  couple 
of  years  ago,  set  up  a  rule  whereby,  in  order  to  have  a  single 
working  group.  Congressional  approval  is  reguired.  It  was 
mentioned  yesterday  a  possible  way  around  that  would  be  to  have 
two  working  groups  and  coordinate  them.  It  was  then  suggested 
that  the  ADPA-M1LC0M  group,  which  is  not  a  professional  society, 
might  become  part  of  CSIWG  and  Congressional  endorsement  sought 
for  it.  Additional  comment  agreed  this  suggestion  had  a  lot  of 
merit. 

Returning  to  the  use  of  technology  by  program  managers,  and, 
based  on  experience  in  the  Navy,  there  is  a  very,  very 
significant  disconnect  between  the  technology  community  and  the 
program  manager.  Program  managers  respond  to  very  specific  opera¬ 
tional  requirements,  a  documented  budget  profile  and  milestones 
with  reports.  The  attention  paid  to  technology  -  leading  edge 
of  technology  -  by  program  managers  who  must  focus  on  delivery 
is  not  done  too  well.  The  connectivity  between  6.1  and  6.2  pro¬ 
grams  and  the  program  manager  has  some  of  the  seeds  of  the 
problem.  There  has  to  be  a  better  way  of  advertising  technology 
to  program  managers  for  technology  insertion  and  planning  for 
future  insertion,  which  is  the  job  of  the  program  manager  who 
succeeds  him.  It  is  not  a  comfortable  situation. 

MlLCOM  IV  should  cover  thoroughly  the  help  needed  in  maintaining 
a  billion  words  of  code.  It  is  crucial.  The  dilemma  is  the 
mortgage  of  supporting  these  systems.  There  is  concern  it  may 
consume  all  available  resources  in  the  near  future.  We  wi 1 1  be 
unable  to  build  new  systems  unless  we  focus  on  new  technologies 
or  new  approaches  for  dealing  with  It.  What  is  likely  is  not 
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supporting  the  systems  that  are  out  there.  We  need  to  deal  with 
that  problem  and  the  working  group  is  good  but  technology  is  not 
politically  neutral.  Nor  is  its  introduction.  The  only  solution 
seems  to  be  a  two-tiered  working  group  where  one  tier  has  the 
confidence  of  the  rest  of  the  group,  proposes  a  solution  and  the 
rest  ratify  it.  Attempts  to  craft  a  solution  in  committees  will 
(not  succeed).  People  must  be  identified  who  recognize  they  have 
to  sell  the  solution.  After  the  Battle  of  Midway,  the  Japanese 
realized  they  had  lost  the  war.  They  took  twelve  of  the 
brightest  and  best,  exempted  them  from  military  service  and  set 
them  to  plan  for  the  rebuilding  of  Japan.  What  Japan  has  done  is 
the  main  outlines  of  that  plan.  Okida  and  ten  others  are  alive 
today  and  are  unofficial  advisers  to  the  Prime  Minister.  We  need 
to  find  a  category  of  people,  who  have  had  government,  industry 
and  academia  experience,  embed  them  in  a  broader  community  of 
interest  and  have  them  all  grind  out  a  solution.  We  cannot  get 
there  on  a  serendipity  approach.  There  are  problems  -  who  will 
be  in  the  group  -  will  debate  get  the  right  answer  -  etc.  But 
unless  we  get  something  along  that  line,  we  won't  to  get  the  com¬ 
mon  goals  and  objectives  in  operational  language  that  we  need. 

Participants  will  be  solicited  tor  comments  and  suggestions  for 
M1LC0M  IV. 
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ROSE  M  BARNSTABLE 
ARINC  RESEARCH  CORP 
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CONGRESSIONAL  RSCH  SER 
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WASHINGTON  DC  20540 
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IBM  CORPORATION 
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AUTOMATION  INDUSTRIES,  INC 
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LEON  BLOOM 
TITAN  SYSTEMS  INC 
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BOB  BOND 
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MILITARY  VEHCLS  ENGRG 
ASST  DIR/ELEC 
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ENGLAND  KTIGOEE  00000 


RAYMOND  BROWN 
THE  BENDIX  CORP 
1000  WILSON  BLVD 
ARLINGTON  VA  22209 


MARVIN  APPLEWHITE 
TEXAS  INSTRUMENTS 
MGR  ADV  COMP  SYS  LAB 
P  0  BOX  405  M/S  3407 
LEWISVILLE  TX  75067 


JAMES  C.  ASHBY 
GENERAL  ELECTRIC  COMPANY 
APPLICATION  ENGINEER 
P  0  BOX  4840  (CSP  3-3) 
SYRACUSE  NY  13221 


C  A  BARCYNSKI  II 
COMPUTER  SCIENCES  CORP 
MGR  PROG  DEVELOPMENT 
6565  ARLINGTON  BLVD 
FALLS  CHURCH  VA  22046 


DR  VICTOR  R  BASIL I 
UNIVERSITY  OF  MARYLAND 
CHRMN, 

DEPT  OF  COMPUTER  SCIENCE 
COLLEGE  PARK  MD  20742 


JOHN  C  BECKETT 

HEWLETT  PACKARD  CO 

CONSUL  ,  FED.  PROCURE  ?y  TECH 

3000  HANOVER  ST  ,  POBOX  10301 

PALO  ALTO  CA  94303 


BRETT  BERLIN 
CRAY  RSCH  CORP 
1828  L  ST  NW 

WASHINGTON  DC  20036 


SENATOR  JEFF  BINGAMAN 
ARMED  SERVICES  CMTE 
US  SENATE 
RM  SH502 

WASHINGTON  DC  20510 


THOMAS  J  BODE 

ITT  RESEARCH  INST 

DIRECTOR  IITRI  EAST 

5100  FORBES  BLVD 

LANHAM  MD  20706 


ALAN  BOYETT 
SCIENCE  APPLICATIONS 
2109  W  CLINTON  AVE 
HUNTSVILLE  AL  35805 


NORM  BROWN 
USN 

OFF  OF  COMPETITION  ADVOCATE 
CRYSTAL  PLAZA  5  RM310 
WAHSINGTON  DC  20362 


PETER  CAHN 

COMPUTER  SCIENCES  CORP 
VP,  TACTICAL  SYS.  CENTER 
304  W  RT  38  P  0  BOX  N 
MOORESTOWN  NJ  08057 


LTCGL  JOHN  CARNEY 
USAF 

HQ  USAF  XO-I 

WASHINGTON  DC  20330 


PAUL  CHADWELL 
ADPA 

ROSSLYN  CTR  .  STE.  900 
1700  N  MOORE  ST 
ARLINGTON  VA  22209 


MR  DONALD  A  CHIAFULIO 
SINGER  CO-KEARFOTT  DIV 
PROGRAM  MANAGER 
3  PI'.ER  EDGE  DRIVE 
F AIRFIELD  NJ  07006 


JOHN  C  CITTADINO 
OUSDR.^E 

DIR  THEATER  L  TACTICAL  C3 
RM  3D1 74/  PENTAGON 
WASHINGTON  DC  20301 


RUDOLF  CECCUCCI 
ROLM  CORP 

7700  LITTLE  RIVER  TRNPIKE 
ANNANDALE  VA  22003 


DAVID  P  CHARBONNEAU 
CONTROL  DATA  CORP 
MGR  ARCHITECURE  DEV 
2300  E  88TH  ST 
BLOOMINGTON  MN  55420 


DENNIS  A  CHRIST 
SPERRY  CORP 

DIR  PROD  MKTG,  SPERRY  P«RK 
PO  BOX  43525 

ST  PAUL  MN  55164 


HARLEY  A  CLOUD 

IBM  CORPORATION 

DIR  OF  ENGRG,  SFTWARE  *  IECH 

6600  ROCKLEDGE  DR 

BETHESDA  MD  20817 


DORIS  J  COADY 

ENERGYSTICS  CORP  OF  VIRGINIA 
AN/AYK-14  PROGRAM  COORDINATOR 
1225  JEFF  DAVIS  HWY  SUITE  1500 
ARLINGTON  VA  22309 


DR  ROBERT  COURANZ 
RAYTHEON  COMPANY 
528  BOSTON  POST  ROAD 
SUDBURY  MA  01776 


RONALD  L  COFFIN 

ROCKWELL  INTERNATIONAL 

M/S  124-211 

400  COLLINS  NE 

CEDAR  RAPIDS  IA  52498 


JAMES  £  CRICKEY 
CONTROL  DATA  CORPORATION 
6003  EXECUTIVE  BLVD 
ROCKVILLE  MD  20852 


JOSEPH  CYR 
ADTECH 

7923  JONES  BRANCH  DRIVE 
MCLEAN  VA  22102 


ALEXANDER  E  DAVIDQFF 
APPLIED  PHYSICS  LAB 
JOHNS  HOPKINS  ROAD 
LAUREL  MD  20707 


MICHAEL  W  DEEGAN 
TELEDYNE  SYSTEMS  CO 
WASH  REP 

1501  WILSON  BLVD  .  STE  900 
ARLINGTON  VA  22209 


DALE  A  DENNY 
LOCKHEED 

RESIDENT  MANAGER 

800  OAK  RIDGE  TRP  SUITE  103 

OAKRIDGE  TN  37830 


BARRY  C  DEROZE 
TRW 

MGR  ADVANCED  SYSTEMS 
1  SPACE  PARK-  134/5817 
REDONDO  BEACH  CA  90278 


ANDREW  J  DOUGHERTY 
ROCHESTER  INST  OF  TECH 
EXECUTIVE  ASSIST  TO  PRES 
ONE  MEMORIAL  DR 
ROCHESTER  NY  14623 


LARRy  DRUFFEL 

RATIONAL 

1501  SALADO  DR 

MNTN  VIEW  CA  94043 


JAMES  F  DINWIDDIE 
GWU 

ASSOC  PROF 

2130  H  ST  NW.  RM  638 

WASHINGTON  DC  20052 


JOHN  C  DOYLE 

RAYTHEON  COMPANY 

MGR  -  DIGITAL/SOFTWAPE  TECH. 

HARTWELL  RD  .  MS  M24-16 

BEDFORD  MA  01/30 


LORRAINE  DUVALL 

I IT  RESEARCH  INSTITUTE 

DIRECTOR.  ROME  OPERATIONS 

199  LIBERTY  PLAZA 

ROME  NY  13440 


ERNEST  DVORAK 

EG&G  WASCI 

PROJECT  MGR 

2150  FIELDS  ROAD 
ROCKVILLE  MD 

20850 

N.  S.  EASTMAN 

IBM 

MGR  SW  ENG  S<  TECH 
6600  ROCKLEDGE  DR 
BETHESDA  MD 

20855 

GORDON  R  ENGLAND 
GENERAL  DYNAMICS 

ANTHONY  M.  FAILS 
LOCKHEED  MISSILES  ** 

SPACE 

DIRECTOR  OF  AVIONIC 

SYSTEMS 

STAFF  ENG 

PO  BOX  748  MZ  2469 

P  0  BOX  17100  BLDG 

30E  T2-32 

FT  WORTH  TX 

76101 

AUSTIN  TX 

78760 

TOBY  FEINBERG 

US  SENATE 

00000 

HERMAN  FISCHER 
LITTON  DATA  SYSTEMS 
8000  WOODLEY  AVENUE 
VAN  NUYS  CA 

91409 

ROBERT  D.  FLANAGAN 
IBM  FED  SYS  DIV 

PARKER  FOLSOM 

3909  HARRISON  ST  NW 

MARKETING  MGR 

9500  GODWIN  DR 
MANASSAS  VA 

22110 

WASHINGTON  DC 

20015 

RICHARD  E  FORREST 
NAVAL  SEA  SYS  COMMAND 
ACQ  INTERFACE  DIR 

2344  DUNFQRD  DR 

FALLS  CHURCH  AV 

22043 

JOSEPH  M  FOX 
SOFTWARE  A  t*  E 

SUITE  1220 

1401  WILSON  BLVD. 
ARLINGTON  VA 

22209 

WILLIAM  L  FREIENMUTH 
VITRO  CORP 

SR  VICE  PRESIDENT 
14000  GEORGIA  AVE 
SILVER  SPRING  MD 

20910 

RICHARD  P  FYE 
GENERAL  ELECTRIC 

SR  STAFF  ENGR 

COURT  ST  PLANT  3-35 
SYRACUSE  NY 

13201 

THOMAS  L.  GABRIELE 
BEND IX 

PRIC  ENG 

W  D.  GEIGER 
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VICE  PRESIDENT  FOR 

OPERATIONS 
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BALTIMORE  MD 
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P  0  BOX  3525 

ST  PAUL  MN 

55165 
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ARLINGTON  VA 

22202 
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SYRACUSE  NY 

13221 
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P  0  BOX  4840  <CSP 
SYRACUSE  NY 
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JOHN  G.  GREGORV 
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JOSEPH  F  GROSSON 
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PAUL  V.  HALBERG 

MAGNAVOX  GOVT.  &  INDUST.  ELEC. 

VICE  PRESIDENT*  SYSTEMS  DEVEL 
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PRODUCT  LINE  MANAGER 
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DIRECTOR*  GOVERNMENT  SYSTEMS 
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MGR  NAVY  PRO  -  FIELD  MKTING 
1755  S  JEFF  DAVIS  HGWY  STE  600 
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1820  DOLLY  MADISON  BLVD 
MCLEAN  VA  22102 
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INFORMATION  SPECIALIST 
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ARLINGTON  VA  22202 


RAYMOND  W.  HINE 
ADVANCED  TECHNOLOGY 
TECH  DIR  DEF  ENERGY  SYS 
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BATTELLE  COLUMBUS  LABS 
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505  KING  AVE 
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ARLINGTON  VA  22209 
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WASHINGTON  DC  20009 
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MGR  ADV  TECH 

2300  E  88TH  ST 
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BRUCE  G  JAMISON 

LITTON  AMECOM 
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ANDREW  H.  JAZWINSKI 
TASC 

DIR  ADV  DEV 

1700  N  MOORE  ST  STE  1220 
ARLINGTON  VA  22209 


ROBERT  F  JEFFERSON 
IBM  CORP 

DIRECTOR  OF  OPERATIONS 
1755  JEFFERSON  DAVIS  HWY 
ARLINGTON  VA  22202 


ARTHUR  F.  JEYES 

GOULD  DED 

SOFTWARE  ENG 

6711  BAY  MEADOW  DR 

GLEN  BURNIE  MD  21061 


LINDA  JOHNSON 
ROLM  CORPORATION 
DIRECTOR  FEDERAL  AFFAIRS 
421  INDEPENDENCE  AVE  SE  #3 
WASHINGTON  DC  20065 


EVERETT  M  JOSEPH 
RAYTHEON  COMPANY 
MGR  ADVANCED  COMPUTER  PROG. 
528  BOSTON  POST  ROAD 
SUDBURY  MA  01776 


WALTER  H  JORDAN 
SYSTEMS  DEVELOPMENT  CORP. 
DIR  GOVT  RELATION 
7925  JONES  BRANCH  DR 
MCLEAN  VA  22102 


ROBERT  E  KAHN 

DEPT  OF  DEFENSE 

DIR  DARPA/IPTO 

1400  WILSON  BLVD 

ARLINGTON  VA  22209 


ELIAS  M.  K ALL IS 
DEFENSE  ADV  RSCH  PROJ  AGCY 
1400  WILSON  BLVD 
ARLINGTON  VA  22209 


ROBERT  W  KEENE 

CONTROL  DATA  CORPORATION 

NAVY  MANAGER 

9907  DEPAUL  DRIVE 

BETHESDA  MD  20817 


JAMES  C  KENNER 

IBM  CORPORATION 

MARKETING  REP 

9500  GODWIN  DRIVE 

MANASSAS  VA  22H0 


GREG  LARSEN 

EMERSON  ELECTRIC 

SR  ENG  MGR 

8100  W  FLORISSANT 

ST  LOUIS  MO  63136 


GERALD  J  KARLNOSK I 
CALSPAN  CORP 

HEAD  COMPUTER  TRAINING  SYS 
PO  BOX  400 

BUFFALO  NY  14225 


MICHAEL  J  KELL  I HER 
VITRO  LABORATORIES 
DEPARTMENT  HEAD 
14000  GEORGIA  AVENUE 
SILVER  SPRING  MD  20910 

I 

CHARLES  KRESS 

ROCKWELL  COLLINS 

M/S  124-211 

400  COLLINS  ROAD 

CEDAR  RAPIDS  IA  52498 


DAVID  H  LEE 

FORD  AEROSPACE 

MGR,  TECHNOLOGY  DEVELOPMENT 

10440  STATE  HIGHWAY  83 

COL.  SPRINGS  CO  80908 


LOUIS  H  LENERT 
INTERSTATE  ELECTRONICS 
DIRECTOR,  MARKET  PLANNING 
1001  E  BALL  ROAD 
ANAHEIM  CA  92805 


J  LFVENSON 
RAYTHEON  SERVICE  CO. 

MANAGER 

305  FELLOWSHIP  ROAD 
MT  LAUREL  NJ  08054 


PETER  J.  LICATA 
ROLM  CORPORATION 
FEDERAL  MARKETING  MGR 
7700  LITTLE  RIVER  TRNPKE 
ANNANDALE  VA  22003 


DR  EDWARD  LIEBLEIN 
OUSDRStE  ( R&AT ) 

DIR  COMP  SOFTWARE  SYS 
RM  3E 1 1 4— ( 400AN )  PENTAGON 
WASHINGTON  DC  20309 


DR  H  B  LYON 
TEXAS  INSTRUMENTS 
SUITE  1006 

1745  JEFFERSON  DAVIS  HWY 
ARLINGTON  VA  22202 


HYLAN  B  LYON 

TEXAS  INSTRUMENTS  INC 

MGR/WASHINGTON  REP 

1745  JEFF  DAVIS  HWY  SUITE  1006 

ARLINGTON  VA  22202 


JACK  MACHANIK 
POLYTECHNIC  INST  OF  NY 
DIR  CENTER  FOR  DIGITAL  SYS 
333  JAY  ST 

BROOKLYN  NY  11201 


R  A  MACMURDO 
AT&T  TECHNOLOGIES 
DEPT  CHF/SIGNAL  PROCESSING 
P  O  BOX  20046 

GREENSBORO  NC  27420 


DR  JOHN  H.  MANLEY 
COMPUTING  TECH  TRANSITION 
PRESIDENT 
82  CONCORD  DR 

MADISON  CT  06443 


ROBERT  MATHIS 
DEPT  OF  DEFENSE 
TECH  DIRECTOR-  AJPO 
RM  3E114,  PENTAGON 
WASHINGTON  DC  20301 


DR  EDITH  W  MARTIN 
OUSD  (R&AT) 

DEP  UNDER  SECRETARY  OF  DEF. 
RM.  3E114,  PENTAGON 
WASHINGTON  DC  48352 


BERNARD  J.  MATULIS 
RCA  CORP 
CHF  ENGINEER 

BORTON  LANDING  RD  101-201 
MORRESTOWN  NJ  08057 


RALPH  MAURIELLO 

LITTON  SYS 

DATA  SYS  DIV 

8000  WOODLEY  AVE 

VAN  NUYS  CA  91409 


CDR  GARY  C.  MAXWELL 
NAVA I R 
543D  JP-2 

WASHINGTON  DC  20361 


SONN'i  MAYNARD 
OUSDR&E  (R&AT) 

DIR  OF  WHSIC  &  ELECTRON  DEV 
RM  3F114  <  400AN )  PENTAGON 
WASHINGTON  DC  20309 


P.  E.  MCELLIGOTT 
GE  CORPORATION  R&.D 
PROG  MRKTG  MGR 
P  0  BOX  8  <  KW-D281 ) 
SCHENECTADY  NY  12301 


WILEr  MCKENI2E 
ROCHESTER  INST  OF  TECH 
DIR  SCH  OF  COMPUTER  SCIENCE 
ONE  LOMB  MEMORIAL  DR 
ROCHESTER  NY  14623 


KENNETH  E  MCVICAR 
THE  MITRE  CORPORATION 
VICE  PRESIDENT  &  GEN  MGR. 
C3I  DIV  ,  BURLINGTON  RD 
BEDFORD  MA  01730 


MAJ  DANIEL  MEIGS,  USaF 

HQ  AIR  TRNG  CMD 

TTXD 

RANDOLF  AFB  TX  78150 


J  P  MELLIN 
CONTROL  DATA  CORP 
MGR  PLANNING  HQN09H 
PO  BOX  0 

MINNEAPOLIS  MN  55440 


ROBERT  E  MELLOTT 

CONTROL  DATA  CORP 

NAVY  PROGRAMS 

6003  EXECUTIVE  BLVD 

ROCKVILLE  MD  20852 


EDWIN  H  MILLER 
RCA  CORP 

DIRECTOR  MARKETING 
P  0  BOX  588 

BURLINGTON  MA  01803 


ROBERT  C  MILLER 
DATA  GENERAL  CORPORATION 
SP  VICE  PRESIDENT  FOR  TECH 
4400  COMPUTER  DRIVE 
WESTBORO  MA  01580 


ROBERT  A  MONGEAU 
IBM  CORPORATION 
1755  JEFFERSON  DAVIS  HIGHWAY 
SUITE  600 

ARLINGTON  VA  22202 


DR  MELVIN  MOY 
NAVY  PERSONNEL  R&D  CENTER 
RSCH  PSYCHOLOGIST 
CODE  71 

SAN  DIEGO  CA  92075 


WAYNE  MOYERS 
RCA 

MGR  MARKETING  DEVELOPMENT 

FRONT  ?<  COOPER  STS 

CAMDEN  NJ  08102 


GEORGE  MURPHY 
DIGITAL  EQUIPMENT  CORP 
MIL  SPEC  SUPP  MGR 
CONTINENTAL  BLVD 
MERRIMACK  NH  03054 


RAYMOND  NOAH 
HONE /WELL 

SECTION  HEAD  GUIDANCE  Sc  NAV 
13350  U  S  HWY  19  SOUTH 
CLEARWATER  FL  33546 


HENRY  NYE 

DIGITAL  EQUIP  CORP. 

MGR  DODIIS 

CONTINENTAL  BLVD  MA02-1/A7 
MERRIMACK  NH  03054 


THOMAS  W.  O'CONNOR 
ROCKWELL  INTERNATIONAL 
MGR  EST  REG/WASHINGTON  REP 
1745  JEFF  DAVIS  HWY 
ARLINGTON  VA  22202 


RADM  WAYNE  E.  MYER 
NAVAL  SEA  SYSTEMS  COMMAND 
DEP  COMMANDER 
COMBAT  SYS  DIRECTOR 
WASHINGTON  DC  20362 


BRUCE  NOEL 
ROLM  CORP. 

MARKETING  MANAGER 

ONE  RIVER  OAKS  PLACE,  MS  110 

SAN  JOSE  CA  95034 


DR  DENNIS  NYSTROM 
ROCHESTER  INST  OF  TECH 
DEAN 

ONE  LOMB  MEMORIAL  DR 
ROCHESTER  NY  14623 


BRUCE  E  OLSON 
SPERRY 
SUITE  307 

1745  S  JEFFERSON  DAVIS  HWY 
ARLINGTON  VA  22202 


STANLEY  E.  02GA 

RCA 

MGR 

BORDEN  LANDING  RD 
MOORESTOWN  NJ  08057 


TOM  P  PENAUSKAS 
RAYTHEON  CO. 

MGR 

528  BOSTON  POST  RD 
SUDBURY  MA  01776 


DAVID  W.  PIDWELL 
ROLM  CORPORATION 
1  RIVER  OAKS  PLACE  MS  110 
SAN  JOSE  CA  95134 


GEORGE  C  PORTER 
IBM-FEDERAL  SYSTEMS  DIVISION 
9500  GODWIN  DRIVE 
MANASSAS  VA  22110 


JAMES  PELL I CANO 
IBM  CORP 

COMPUTER  MARKETING 

OWEGO  NY  13827 


MICHAEL  C  PERON 

NORTHROP  CORP 

MGR  7433/Y33 

500  E  ORANGETHORPE  AVE 

ANAHEIM  CA  92801 


COMMODORE  S  F  PLATT 
COMPETITION  ADVOC  GEN 
NAVY  DEPARTMENT 
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